Test Driven Development without the tests

For me, designing software without Test Driven Development is just unthinkable. TDD helps me in a lot of ways. It helps me to split large tasks into smaller pieces, it helps me to focus on a small part of the software and the task I am currently working on. It also helps me to keep my code as simple as possible.

TDD recap

A big part of Test Driven Development is writing tests to automatically test the code you have to write. But in order to write code we mostly follow the following steps:

1. Write a test and see it fail.
2. Write a little code and see the test pass.
3. Refactor.
4. Go back to step 1 to write more code...

By writing the tests first we can concentrate on the task at hand and keep the code as functional as possible. Basically we start using the code before the code exists and we make it possible to make the code easy to use.

By writing just enough code to pass the test, we keep the code small, clean and easy to maintain.

Refactoring is the part where we cleanup the code. We remove duplicate code, make code easier to read and understand by renaming variables to make their intend clear, extract methods to get single responsibility, etc, etc, etc...

TDD without tests

But what when it is not possible to write tests? Sometimes it is hard to think that it is not possible to write tests for some peace of code, but there are quite a lot situations where automated tests are not possible.
A few examples when you can see tests aren't worth writing:

• During the setup of the test you have to instantiate half the application.
  Most of the times this is an issue when the application or a library you use depends on a lot of configuration and on some huge god classes.
• You need access to hardware / hardware api's
  This could be anything actually, simply painting to the screen, play audio, send a document to the printer, get data from a scanner..

The first point is very difficult to handle and personally I think the best solution is to try and use an other library, or to decouple as much as possible from this library.
For hardware (api) access it is also possible to create wrappers to hide the real implementation, but still you can't test that the image is correctly displayed by the api. Still I believe it is possible to apply the principles of TDD in these situations.

Lets take a look at the steps we take when performing TDD and how we can apply them when we want to show some character images on the screen.

1. Write a test and see it fail.
2. Write a little code and see the test pass.
3. Refactor.
4. Go back to step 1 to write more code...

"Writing a test and see it fail" is the most difficult step. First of all let's define what we want to test. Start small and say for example "I want to show a single character bitmap on the top left corner of the screen".

Of course this is only a small task and easy to define whether this test will (visually) pass or fail, but for more complex situations it would be a good idea to draw some mockups.

"Write a little code and see the test pass" is not too difficult, but it could be harder than you think. It is difficult to restrict yourself to write as little code as possible.

The difficult thing about refactoring this kind of code is that you have to run the application time after time to make sure you don't break anything. With bigger applications this can be time consuming, but by creating smaller test applications that show only what you want to test this tasks will be doable.

Conclusion

TDD is a very useful concept and to some extend it could also be applied without tests. The key to success is taking small steps, just like you would do when writing tests.

Get classes based on Interface with Linq

This weekend I was searching for an easy way to get all classes which implement an given interface.
After searching I found an easy way to get the classes by given type. Using Linq getting the following code:

var type = typeof(IMyInterface);

var types = AppDomain.CurrentDomain.GetAssemblies()

.ToList()

.SelectMany(s => s.GetTypes())

.Where(p => type.IsAssignableFrom(p) && !p.IsInterface);

First blogpost :)

We, David and Wim, are friends and working together as programmers for the same company. We are .NET developers. We have experience with C, PHP, Java, jQuery / Javascript and always searching for new ideas and frameworks.

In our blog posts we want to share our experience while developing. Have fun and keep our blog in mind ;-)