Tuesday, January 8, 2013
Doing unit testing with mocking is a tool, not a silver bullet. Unit tests mixed with behavior testing can be very effective at finding these kinds of bugs and Mocks allow you to create and test against foreseen conditions. While TDD can help expose bugs, unforeseen data conditions can pass though unnoticed, tests only test what they are told to.
Something else to keep in mind is behavior and unit tests are only a small part of the testing tool box that also includes: integration tests, performance tests, automated UI tests, etc. and that’s what these are tools. How effective they are depends on the user, a funny quote I once heard is “A tool runs tools, a craftsman uses them”. You can run your code coverage tool all day long and say “look I have 80% code coverage” but this doesn't mean your code is well tested, it just means it has test that run though it, and can hide untested code.
One commenter on the article said something to the effect that what they where working on requires to much performance to be testable. I would like to state this is B.S. you can make testable code that has just as much performance as not testable code. You may have to change how you test the code, or use different design or testing techniques for example Dependency Injection isn't required to make testable code, if it's not fast enough use greedy constructors or lazy load properties. If you need to make a black box class for performance, you simply do integration tests around it.
In the end, saying TDD isn’t of value because it didn’t catch bug xyz is like a carpenter blaming his hammer for hitting his thumb and not the nail. On the other side it’s just as ridiculous to say “I can build a house” simply because you own a hammer and some nails.
Wednesday, October 17, 2012
There is an old joke “arguing with a developer is like wrestling with a pig in mud, after a while you realizes he/she likes it”, and there are a number of reasons for this, as a group we tend to have strong options, stubbornness, know-it-all, and ego to name a few. Some of this is what makes us good developers, a lot of it is what makes us irrigating to other people.
I personally have been in my fair share of heated, angry, and down right nasty 'discussions' and in the past I may have been guilty of using the force of my will to get teams I have been on to do things 'The right way'. Even joking about being the “a-hole developer”, and as I matured as a professional, I realized even if I win like this, at what cost? I began to realize it was beginning to effect my health and that I didn't like who I was becoming.
This is not to say we can’t have discussions from different points of view, have different opinions, be a pushover, or not think the other side is off their rocker. Far from it, but we need to keep it civil and positive. Last I checked we (as developers) are paid to solve problems, not prove we are right. The heart of collaboration is taking different points of view and coming up with the best solution and we can’t do that if we are trying to prove we are right.
It’s ok to have strong opinions, I have more then a few, but it is also important be open minded, be willing to look at what the other side is saying, and come to an acceptable resolution on how to solve the problem. Admitting when you are wrong, or at least not completely right, can be very hard. Ultimately, be willing to work as a team, and if the team decides to do things “wrong” then that’s what the team wants. If you are working with a team that insists on doing things “wrong” and you are unable to contribute, then maybe this isn’t the team for you “If you can’t change where you work, change where you work”.
Wednesday, June 27, 2012
The basic idea is NCrunch automatically runs your tests in a parallel process giving you continuous testing that’s integrated into Visual Studio. It intelligently runs tests automatically so that you don't have to, and gives you useful information including code coverage and performance metrics while you work.
Here is an example of the inline test results
here is a screenshot of the test runner
and this what the coverage looks like
it’s not quite as detailed as I would like, but not bad.
This isn’t going to be a replacement for my copy of Resharper and DotCover but at the same time, I don’t see a problem with running both. This could defiantly save me a lot of time waiting for test to run and if I want more detailed information I can still use dotCover.
This is a free tool that so far has really impressed me, for more information go to the NCrunch home page athttp://www.ncrunch.net/
Monday, June 25, 2012
Thought it would be interesting to show the solution I used for testing, lets say we have a simple method for updating an employee record.
fairly simple, you call AuthRequests to see if the user and update the employee and then you update the employee. Here is an example test class for it
the only problem is the tests still pass if the method looks like this
so lets add some sequence tests, basically we add a counter and a dictionary<string,int> to record what was executed and it what order using the Moq callback.
for the full source see the sample application here.
Wednesday, June 20, 2012
A traditional TestFixture might look something like this
Having a fairly large TestFixture with a lot of tests for the different functions of the method being called.
When doing behavior testing the idea is to test a code path for a specific context vs. testing for all possibilities a method could result in, basically breaking it down into much easier to read parts.
To do this we set up a base or abstract class that has a context method for setting up your test and a because method for running it, here is an example of one using generics
next we set up the the test fixture
a couple of things you may notice is first the the name is fairly long and descriptive, the idea is you want to make it easy to read the test results to know what your testing, in this case requesting employees from Seattle, WA.
The next thing you may notice is we don’t have as many test methods, sense we are only testing for what happens when we are getting employees from Seattle, WA. that’s all we are testing for. This may produce more test textures classes but at the same the test fixtures are more targeted and give a better description of what you are testing making it easier to read/maintain later and is sometimes called executable specifications, where you can find out the intended function of a class or method simply by reading then names for the test fixture and tests. For more examples of unit tests vs. behavoir tests see the sample application in the sample code repository.