Here it is a flow of random thoughts about Test Driven Development. Naturally IMHO.

• TDD is not about testing application is about design application, and have a (nice) side effect that creates a suite of tests
• The Test obtained with TDD does not cover all the cases, but you can write more test when you need new cases or find a new bug
• The code written in TDD is less and it focused on the needs
• The code written in TDD is more orthogonal and simpler to maintain
• The first red bar is the signal that the test is testing something (and it is very important)
• The tests cannot contains if, switch, etc…so they need to be simple
• Learning TDD is difficult: the impact is the same that you have when passing from structured programming to Object Oriented Programming
• Learning TDD requires times and perseverance
• You cannot learn TDD reading articles and books, you must try it
• Every piece of code is testable
• Testing that the tone of red is that the user likes is not a task of TDD
• With the right use of Mock Objects you can test that the gradient is correctly set
• The test cases comes from the User Stories written with the customer and then they responds to requirements
• The Team that use TDD must be skilled enough…and Pair Programming helps a lot
• The Test code is bigger than the tested code
• TDD force you to think about what you’re writing
• TDD force you to declare what you need before writing something
• TDD put the developer to the client side of his code and so help him to write better interfaces
• TDD helps you to write cleaner and decoupled code
• The Integration Tests helps you to understand how your class interacts with others
• When you need to refactoring your code you can start from tests
• Tests are documentation: read a test is a great help to understand how to use your class
• TDD does not guarantee that you code doesn’t contains bugs
• TDD guarantee that old bug doesn’t come to life again
• The start up cost of TDD is write off during the life of the project
• The TDD reduce a lot the time needed for manual testing
• With TDD the debugger is used like a surgery tool
• TDD helps you to simplify the problem dividing it in small part and every solved part is a small step to the final solution
• Every test case is a single functionality: if one test fail you have only one problem
• If  you have two red test you have two distinct problems
• Every test add a new functionality to the code
• Is difficult to test multi threading applications
• It’s expensive testing the UI, but there are patterns that decrease the UI code (MVP/MVC)
• The integrations test against database help you to know if the database and the queries are ok
• TDD force you to written less encapsulated code to  make it testable
• TDD force you to write independent object and to inject all the dependencies
• Write test after code is not always possible
• TDD is not a silver bullet (but it’s help a lot!)

By now we have the date, 24Th January 2009 and the location, the Breda Innovation Center in the offices of SourceSense. The agenda is in defining phase e you can say what you prefer by voting on our poll.

But we have one session defined, the one on IronRuby because  Ivan Porto Carrero (the author of  IronRuby in Action) will came from Belgium for talk with us at the conference…you can’t miss this opportunity!

The format is the open space, so no speakers ma space for everyone to talk, ask, show code and tell your experience about .NET development and agile practices.

You can subscribe to event here: http://altdotnet.org/events/7