I cannot say I am a big BDD-er. I have used it for commercial projects, mostly to define complex scenarios for complex pieces of code (a custom discount engine comes to mind) but it comes with a price tag that I am not willing to pay for the majority of tests I write (unit tests). I am not going to describe what BDD is, philosophy, syntaxes, flavors… I am just going to mention my experience with a couple of tools one can use if developing for the .NET Framework.
Configuration in enterprise application is a fact of life. My take on it is as follows: delay it as late as possible and hard-code in anger until someone asks for a change. Then, accepting the fact that is likely to happen again, the value is pushed into configuration. Configuration can be as simple as a collection of key-value pairs. But sometimes, configuration needs to be more complex than key-value pairs; just imagine some sort of hierarchical structure or a simple collection of related values.
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.
Anonymous delegates, lambdas and their akin are here to stay and make our life easier. Despite being in the framework since day one (well, not in their anonymous incarnation and definitely not in their lambda form) delegates have had some sort of “Cambrian explosion” in their usage since the advent of LINQ. More and more developers have been exposed to […]