Wednesday, November 5, 2008

Characterization Testing

Test that code

Michael Feathers introduced the concept of using characterization testing in order to provide code coverage for untested legacy code. This technique is essential for anyone working with existing production code because it ensures that the external behavior of the system under modification is not effected as it undergoes internal changes. The problem with this technique is that it turns people off to testing despite the fact that this technique often helps to identify design problems in the system under test.

Unit Testing Is Stupid

On one occasion I was paring with a developer who was a staunch supporter of "test automation" but did not believe in unit level tests. His organization however mandated that every developer write unit tests, so he came to my team for help with writing tests for the system. I started by writing the first test....
def test_do_it
assert_equal "no clue what you do", @sut.do_it

end

... he said, "What are you testing? That really doesn't make any sense". I responded by saying, "I don't know what this class is supposed to do, but I can find out what it actually does by executing it". He scowled furiously at me but I executed it and low and behold there was an error! In disbelief he exclaimed, "what nil object?!?" Yes, we actually found a bug by writing a characterization test! This sparked a conversation among a few team members and it turned out that a misunderstanding of what his class was supposed lead to a bug.



Well not really. He ran off into his cave again writing code without tests in order to fix this problem. However he never came back to me. When I ran into him again I asked how testing was going and he gave me the same spiel about how unit testing is not important. Really? Even though it lead to discovering a BUG!
On other projects where there is just a ton of legacy code and I have to add or correct the existing behavior, we often spend a few hours just writing characterization tests. When I am pairing with someone relatively new to TDD they hate it. Lets just face it, test-last development is tedious. Shouldn't that be reason enough for people to prefer TDD?

No comments: