The purpose of the integration build is to bring potential issues to the surface as quickly as possible. Unit tests run quickly and adding them to the continuous integration build helps flush out defects as close to the beginning of the process as possible. Generally build engines will support unit test framework by directly integrating with them or by providing an ability to execute the test framework and import their results.

It can be challenging to add unit testing to a project that was built without planning to incorporate it. The ASP.Net MVC Music Store tutorial was not built with unit testing in mind, but today we're going to walk through the addition of Controller unit tests, focusing on a controller that directly references Entity Framework objects and implicitly interacts with ASP.Net Membership objects and Request data from the current HttpContext.

I find that often the hardest part of trying a new technology or principle is finding a project that is simple enough to work on in my spare time, yet complex enough to be useful. Several weeks ago I came up with the idea to use a common project to serve as a platform for additional projects and experiments. The first project, build an automated pipeline that will verify the project remains stable (or notify me when it isn't) throughout its lifetime.

I met Denis and Sebastian over a year ago when I attended their session on test driven database development. Since then, I have been using tSQLt to add unit tests to my database. The following post was written by Denis Lloyd Jr. About the Series…

Recently I decided to start doing JavaScript code katas. I've been using JavaScript for around ten years, but there there are still a lot of aspects I don't know well or that I could use more practice in. Case in point, I had never used a unit testing framework with javascript.

For someone that is just interested in trying out Unit Testing the number of topics out there can seem overwhelming. From passionate articles about using TDD, to deeply technical articles around the differences in mocking frameworks, to complete sidetracks into architecture theory and how to make code more testable...just learning enough to get started and try out Unit Testing can seem like you need weeks of classes.

Last week I had the pleasure of presenting at a .Net Code Camp on the topic of Unit Testing. A key theme of the session was barriers to adoption and the values we can achieve using this tool.The main barrier to my adoption of Unit Testing was the idea that writing twice as much code would increase the value of my work. Twice as much code, as was pointed out in a response to my post two week's ago, sounds like higher maintenance costs, higher initial development costs, and a greater opportunity for bugs.

Saturday started off cold and rainy, but it didn't matter because, for over 100 of us, there were more important things going on. Namely sessions ranging from the one I presented, Unit Testing, to specific C#, jQuery, database, ALM, Silverlight, Ruby, and Python topics. In fact there were so many specific topics and I heard so many good things about all of the sessions that I wish I could have twinned or tripled myself to attend them all.

There is a long list of reasons not to use Unit Testing in your current projects. In fact I was able to make such a long list of reasons not to use automated Unit Testing that I wasn't able to use them all in my presentation for the Raleigh Code Camp this coming weekend.

In dutch there is this saying.

Een ezel stoot zich nooit tweemaal aan dezelfde steen.

A literal translation would go like this.

A donkey never bumps into the same stone twice.

or

Even a donkey does not bump himself twice against the same stone…

A less literal translation would be this.

Fool me once, shame on you. fool me twice, shame on me.

So unit testing is all about being the donkey or the fool or both ;-).