Beginning with the classic calculator example he has the class go through possible values to confirm that a + b works. How about 1 + 1? Well, someone will wonder if the fact that the two numbers are the same means something. What about 1 + 0? No, zeros usually need their own tests. 1 + 5? Why 5? 1 + 2 are good because they are obvious, and they start to form an expected vocabulary, like i and j for loop variables. You see them, you know what they mean, and you don't have to think. He had a wonderfully piquant image for driving this point home. "Imagine there's a serial killer who knows your address and will be reading your tests. If he sees a five, he's going to wonder why you chose that, and he's going to come by your house to ask." Rare inspiration for keeping things obvious!
A few other points nicely brought home:
- Don't use the NUnit message parameter. Your name should be sufficient.
- No vars in tests!
- Prefer factory methods to SetUp. (Not sure about this one, especially when testing Dependency Injection consumers with a lot of mocks.)
- Follow a rigorous naming convention. He suggested UnitUnderTest_Action_ExpectedResult.
- Split your Integration Tests into a separate project. Your unit tests should be a safe zone where stuff only happens in memory, and your developers don't have to worry about hitting Run.
- TestDriven.Net allows you to debug production methods with a right click, and runs tests very quickly. (The video is before the days of the miraculous tool NCrunch.)
Not really new material for me, but it has definitely sharpened my thinking on these topics. Looking forward to the rest of the course.