As the reader might have notice, I am a big advocate of testing. During the years that I have been practicing some flavor of testing I have been developing, borrowing and using small little classes (or bigger ones) and techniques to make my life easier and my code suck a little less.

I have decided that I might as well share them with more people and, who knows, the benefit might become mutual. That, and the fact that my code will be improved as it makes its way into the new projects, is why I am launching Testing.Commons.

Testing.Commons

This project will contains code that helps and supports testing in any way. No external dependencies on any framework or tool should be needed.

Testing.Commons.NUnit

NUnit is my weapon of choice when it comes to unit testing and I even use it to drive some other types of tests. One of the features I have come to love the most is the ability to extend its assertion model with custom-developed constraints. This project will contain, most than anything, some useful custom constraints I have used though the years.

Tool changes

This may sound a little harsh and will leave some people disappointed, but I will focus my efforts only in .Net 4 as there are newer features that I definitely want to explore, such as dynamic and default parameters, for their potential to improve code expressiveness and clarity.

I have been using Subversion for some time and used Google code to host my other OSS project: NMoneys.
Not that I have been let down or limited in any way by the tools or the hosting, but I a willing to get my head around Distributed Version Control Systems. Everyone is jumping onto Git and github and that is all fine. I am not (for the moment). I will give Git hosting in Assembla a try (moved to GitHub, sorry). If it does not work for me I can always change, can’t I? We are blesses with multiple very cheap (free) hosting choices, time to take advantage at last, right?

NuGet has been proved mature enough to be considered as the solely delivery method of libraries such as these, so I will continue leveraging two dependent packages. I am still no decided whether I am going to support Ruby Gems, but no door is closed.