You can find a more detailed minutes I wrote in French on Alt.NET France site. I give here a quick synthesis of the conclusion I take from this meeting.
The presentation started with an overview on why testing or why not testing? The discussion raises a lot of stereotypes : "longer", "more expensive", "I'll make them later" (=never ;)) and so on...
Then we get to when testing is useful (and indeed more or less why) :
- get code that just reveals developer intention (not more),
- test at the right granularity,
- protect yourself against inevitable application changes (regression),
- loss of time in repetitive debugging and other test console applications which are not reusable.
- make test first else you never will...
- make simple test first, and increment complexity step by step,
- don't try to conceptualize/develop the perfect thing on first try (let iterations drive you to the most accurate design),
- use some UML diagrams to guide your global intention but do not lose yourself in details,
- use the following virtuous circle : intention > test code (do not compile) > code to compile test code that fails the test (red test) > code that passes the test (green) > refactor (your code or your tests, not both in the same iteration)
- write test correctly = AAA : Actor, Act, Assertions (be careful of tests without assertions)
- a declared bug needs a test to ensure its correction
- always run all the tests (which should be automatic and fast)
- Apply patterns : dependency injection, GoF, M-V-VM for WPF was some of the examples, DDD...
- Use mocks/stubs to isolate tested objects,
- Continuous integration : to build and run tests continuously (and much more...),
- Code coverage : beware of 100% coverage illusion, it does mean that your code is perfect because of entry data combinations problem.
- code documentation (executable specifications),
- protection againts regressions and during refactoring,
- accurate and flexible design for your code.