It was a good group at the unit testing BOF. Here some notes, done from memory the next day. The BOF was facilitated by Ives Tuyaerts. While the majority of the talks centered around NUnit testing strategies, war stories and ideas, Ives had probably the most interesting ideas of all. He was interested in generating tests automatically from use of the application. He tried different approaches including using context bound objects, class and method attributes and finally using the profiling apis to “inject IL into the code as it was being compiled into IL” which allowed the generation of tests based on the various events that were happening. While not prepared to show examples yet, he thought this approach would work and hopes to flesh out the idea further. He may release this as a Sourceforge project if things go well.
Most present were already doing unit tests. The creator of NUnit (James Newkirk I believe) was there and had a lot of advice to give people. Quite of bit of that advice, and of the discussion was around the difficulties of writing and testing UI code or code that produces binary files like tiffs or large xml data files. For UI’s the best advice is to create those interfaces as thin as possible to help create regression tests for those objects. This also led to a MVC discussion. A long discussion of mock objects came up as well with people talking about “boundaries“ as an especially important thing to understand when writing unit tests. A good idea presented for binary files was to create “good” files during your build process that can be used for file compares during the unit tests.
A few shared stories about what to do with existing code that had no tests written, and while there was no consensus, the clearest voice, and one I just happened to agree with, said that the only good choice is to not write tests until you are going to modify the old code. Then, write a test that passes with the old code. This has the added benifit of giving the developer a chance to really digest and understand that code before the modifications are made. Finally, use the new tests to refactor or modify the old code.
Coverage testing remains absent in the .net world, particularly if you want to have your coverage tests done with NUnit. Rational PureCoverage was favorably discussed, but Rational Robot was not and a lot of war stories surfaced about difficulties with tools like that. It’s a really difficult problem, trying to capture user clicks and turn these into tests that can be run for regression tests. This is apparently even more true for Visual Studio designer tools where an excellent option was offered of preferring VS macros.
Well, back to a session. Both the Avalon and Whidbey presentations have me drooling.