Unit testing continued - dealing with changing requirements.
We’ve been doing a lot more concentration on unit testing at work lately, and a question has come up. What value do automated unit tests provide?
In the previous post, we had setup our basic WCF project to play around with for unit testing. So let’s get to testing!
In the previous post we got our first tests set up with moq. So now let’s see about creating some unit tests to go along with our WCF services.
In the previous post I started exploring unit testing, specifically with moq and for WCF services.
We had a new team lead start recently, he seems to have had a fair amount of experience in areas I’m only vaguely familiar with, mostly through reading. One of the first things being pushed for is a concentration on unit testing. While I did begin implementing some tests into our codebase a few months ago (around 250 so far), I feel that there’s still a long way to go. Luckily Chris is here to help impart knowledge to us, hooray!
The simplest way I can think of to explain a build server is to imagine hiring a brand new developer for each code check in, giving them explicit instructions to accomplish the build, and letting them go. Maybe that requires a bit of explanation - the idea of a build server is to provide a reproducible set of instructions/steps to accomplish building your application from start to finish without requiring additional input from the developer checking in the code.
