Dotmad.net

Another useful post from Phil Haack, this time showing how to write multiple culture tests using the mbUnit framework and the MultipleCulture attribute.

• If you are using DUnit for unit tests, consider the DUnitLite and DSpec addons.
• Read this post regarding calling .Net code from Win32 Delphi using C++ code (another way do to this is using COM objects)
• This is why you should move to C#.

Guy Kolbis wrote a post containing a sample for integrating NUnit tests with the VSTS testing system.

The Composite UI Application Block, created by Microsoft’s patterns & practices team, is a reusable, source code–based component based on the Microsoft .NET Framework 2.0.
It provides proven practices to build complex smart client user interfaces based on well known design patterns such as the Composite pattern, in which simple user interface parts can be combined to create complex solutions, but at the same time allowing these parts to be independently developed, tested, and deployed.
In other words, it separates UI related logic and the business logic behind it to separate classes, making it easier to test and refactor you BL code without touching the UI and the other way around.
As it turns out, there is a WIKI resource on the subject, called CABpedia.

Roy Osherove wrote a nice post detailing the mocking tools out there. Seems most people recommend Rhino mocks.
Scott Hanselman also recorded a podcast on this subject a while ago - for people considering the right mocking tool I recommend this podcast.

Leon Bambrick (aka secretGeek) wrote a post about a possible conflict between TDD and agile, claiming TDD may be YAGNI code:
“Test-Driven Development (TDD), on the other, states unequivocally that it’s worth writing extra code, lots and lots of extra code, up to five times as much code you’d write otherwise. The reasons for this are: it may stop bugs from escaping your desk — and it may help out when you need to alter the design later.”

Phil Haack countered by writing:
“Well you don’t know in which specific ways your client will change his/her mind, which is why YAGNI is applied there. But you *do* know somewhere down the line, you’re code will have a bug or have to change, but you don’t know in which way it will have to change up front.“

Do I?
Suppose 10% of my code may have to change in future, either because of requirements change or due to bugs, isn’t writing tests for the remaining 90% YAGNI?
Maybe I should start writing tests for a code section only after I need to change it, as Phil later writes:

“Lastly, part of TDD is also how you react to a bug. Say you find a bug in method X. First, write a unit test that exposes the bug. In other words, write a test that fails because of the bug, but should succeed if the bug doesn’t exist. Now fix the bug. Make sure the test passes. And rejoice that you now have an automated regression test for that bug. It’ll never get introduced (in that way) again.“

I think TDD is best practice when you are writing a framework or an API, I’m not so sure it’s the best approach when you are writing a custom application.