This is the start of a series of posts about Clean Code. I’m going to pick some topics from my cheat sheets about Clean Code and Clean Test Driven Development and explain them in more details.
Today’s topic is
Nested code should be more specific or handle less probable scenarios than unnested code.
In my projects, we use a lot of open source libraries like Ninject, xUnit, Machine.Specifications, FluentAssertions, StyleCop, Moq, statLight, AgUnit and of course the project I lead myself: bbv.Common. These projects are really cool. But sometimes of course, we need something that they do not (yet) provide. Like adding Machine.Specification support in FluentAssertions or a faster runner for xUnit unit tests under silverlight with AgUnit and statLight. Therfore, we download the source code and...
We use a lot of state machines in our projects. We use them for abstracting instruments that we control, controlling when user input controls have to be enabled or disabled and for other things. State machines are great for these kind of tasks (much easier that nested switch statements anyway) but they provide a big challenge when developing software test driven. This is due to the fact that they are of course very state full and often active (running on their own worker thread). Here are some...
I’m working in an agile software development team which develops a fairly complex automation system for manufacturing facilities. We are using Test Driven Development as our main tool to improve the overall quality of the code. We all knew that we are going to have a large number of unit tests during the life cycle of the software. Before we started writing unit tests we decided that we need a test naming convention.