Top 3 misconceptions about Unit-Testing and TDD

Most experts seem to agree that writing tests is a prerequisite for professionalism. Michael C. Feathers defines legacy code as “code without tests”. Robert “Uncle Bob” Martin claims: “it has become infeasible for a software developer to consider himself professional if he does not practice test driven development.”

However many developers feel that they are slowed down by writing and maintaining even more code (the actual code and the tests).
How often did you:
– Need to fix broken tests?
– Ask yourself “why should I test this simple code?” just to discover a bug there a few weeks later?
– Need to throw away a large set of tests because the tested code was refactored?

Most of these issues are the result of misconceptions most developers have about unit testing. In this article I want to highlight the top 3 ones I experienced in the last years:

Misconception No. 1: Unit testing is a method by which individual units of source code are tested
Correct: Unit test is a test running in isolation (from other unit tests)
According to Wikipedia unit testing “is a method by which individual units of source code … are tested to determine if they are fit for use”. This statement is plain wrong! We should not test code but rather test functionality. Behavior-driven development was developed by Dan North as a response to this issue. Kent Beck the inventor/re-discoverer of TDD himself never bound unit-test to a unit of code, but to a unit of functionality. His definition of a unit test is simply a test run in isolation from other unit tests. This means that we can execute any tests in any order or even in parallel without the tests interfering with each other, which is a prerequisite for fast feedback.
Instead of writing a test-class per class we are testing and mocking all the collaborators we should instantiate the whole object graph and use the public API (the functions called via the user-interface or service calls) to verify it works correctly, just mocking the UI and the database (and other things that break test-isolation).
The result are much fewer, much more valuable tests that usually don’t break then refactoring, which brings us to the next point:

Misconception No. 2: The main purpose of unit tests is to verify correctness of code
Correct: The main purpose of unit tests is to enable refactoring
Only a small percentage of bugs are found by tests written by software developers (around 20%). This alone is far too low to weight against the effort necessary to develop and maintain tests.
The real benefit is that once we have Kent-beck-style unit-tests in place we can refactor the code without the fear of breaking something. Since we test against the public API and not against implementation details, we no longer have an excuse for not cleaning up and simplifying the code.
The results of higher code quality are far fewer bugs, better extensibility and faster deliveries.

Misconception No. 3: Unit-testing means that we need to test every class
Correct: During the refactoring phase in TDD you are not allowed to write tests
If you are simply refactoring your code you are not adding new behavior, you simply rearrange your code. This means that if you test against a public API (which didn’t change) all the refactored code should be tested as well. There is no need to add tests against extracted classes since they are simple an implementation detail. If you still add tests against these classes they become obsolete as soon as you do any further refactoring.
You still can have tests for internal classes as a help during the refactoring but once you are ready you can delete them to reduce the maintenance efforts.

Further information:
1) Ian Cooper: TDD, where did it all go wrong
2) Specification by Example
3) Test Driven Development. By Example

Unit testing done right – Better then sliced bread

Maybe the biggest thing since the rise of object oriented programming is test driven development. It’s also as hard to “get”. To help you on your journey, here some tips:

  • Have patience. Good unit testing need to be learned (like OOP, also see “TDD, What a bitch”). Use code-reviews of good unit-tests to learn good practices.
  • Again, have patience. Don’t skip unit-testing after some time. If you need to change tests often try to find the reason why and solve it. In many cases it’s actually a design issue (see next point). Everything falls with cleanly separated (and therefore testable) layers and DRY code. The need to reduce the dependencies for testing using mocks/stubs. “Duplicate code always represents a missing abstraction.” Robert C. Martin in Clean Code Tips
  • Group tests by the user-story they are testing. This ensures that you test the right thing and everything that belongs together is in one file. Use user-stories to define what feature is needed. Use BDD-Specs to describe the details of how a feature should behave. A test is simply a specification translated to code.
  • Tests should not depend on each other. Each test should be able to run correctly without any other test to be executed beforehand.
  • Tests need to be short (no scrolling). A better name for unit tests might be microtests. They just check one thing per test case. This helps to precisely identify where the bug is located (no need for debugging). It also helps to avoid brittle tests ( = tests that need to change often). If tests are too long, there is a good chance that the code under test has too many responsibilities and need to be split.
  • Run microtests as often as possible (best after each compile). Therefore make tests fast. Don’t test the database if avoidable. Don’t test more then one component at a time. More complicated, longer running tests (usually integration tests) can be run over night using an continuous integration server.
  • Microtests can be used to speed up implementation (“Need for speed”). They are a replacement for starting the whole system to check out whether the implementation works correctly. No monkey-testing no more!
  • While writing tests, think of everything that might get wrong (e.g. test whether code throws exception on invalid input, …). Many people tend check only whether the code behave well then it gets correct input. However code should always behave correctly (e.g. not crash) independent on the input it gets. This helps to write more robust code (again less debugging).
  • Write tests before writing the code. It helps to be more clear about the requirements and help to focus the programming efforts. In software development typing is never the bottleneck. Thinking is. Tests make development faster because they help to focus: “How TDD and Pairing Increase Production” and “They’re Called Microtests”
  • Let the tests drive the design of your API. Also see “Unit tests: An API design tool

More on this topic:


Unit tests: An API design tool

Many people think that unit tests are written to catch bugs, however this is only partially right. Unit tests might be a valuable addition to regression-tests and increase a developers productivity, however people might miss the actual benefits of the test-first approach.

Unit testing supports developers in several ways:

  1. For static typed languages unit testing helps to make the code more robust, since there is a good chance that it catches bugs that the compiler won’t find
  2. For dynamically typed languages unit tests are the only way to simply verify the correct behaviour of code.
  3. Unit test are a safety net for refactoring. It’s much easier to change code if you can quickly find out whether this change breaks some critical functionality. Creating more and more tests increase the confidence of doing things right (not breaking something).
  4. Unit tests are documentation. Good tests are very easy to read and since the code needs to pass all the tests all the time, you can be sure the documentation is up to date. While writing tests won’t somehow magically make the requirements clear, specs are up to date.
  5. Unit tests help the programmer to concentrate more on an easy to use interface of the class instead of worrying to early about the internals.
  6. Well-tested code tends to become more extensible, since developers learn to minimize the exposed API of a class (less to test), write smaller classes (easier to test) and create interfaces at the right place (to facilitate testing).
  7. Writing tests and reflecting on that practice as an integral part of the programmer’s job will make it more likely that programmers will think of unusual failure cases, know what kind of test is most appropriate to exercise each case, and protect the system against them.
  8. Making TDD right means to realizes that it is not about testing but about defining behaviour. It helps to discover the API of the code under test.

Test first is API design! Unit tests help to find and eliminate inconsistencies in design by capturing the reasoning and circumstances for choosing certain way to implement an feature. While writing unit tests you are creating the first “user” of it. You start the first time to think clearly about a API the class provides. You think about how the class should react to invalid input, invalid order of method invocations and all the other “edge cases”. Therefore unit tests are the first step to formal reasoning about a technical specification.

Then writing Unit tests, I suggest to do the following:

  1. Think what is the core problem you want to solve.
  2. Think about the edge cases that might occur. Don’t forget that exceptions are part of the interface! Exceptions don’t necessarily signal something terrible happening, but rather explain the cause for not doing what the object was asked for.
  3. Model the actual API you want to create (the interface) by using it while writing the test code.
  4. Code coverage helps to identify areas of the spec that might have been overlooked. 100% Test coverage however is neither a sign that the code is bug free nor working correctly and it might not increase code quality at all. However it might still be useful to identify parts of the code that need your attention.
  5. Good OO code often focus on interactions between components of the system (it’s behaviour). To test such code, the use of Mocks is essential.
  6. Not all domains are easy to test (e.g. computer visualization), so keep in mind that unit-tests can’t be applied everywhere. However it might help to think of ways to improve the (manual) test-process.

Behaviour driven development is basically unit testing done right. For more information look at:

Help killing Internet Explorer 6

Help killing Internet Explorer 6 using the banner provided on the linked website.

Most of you certainly know that there are huge differences between different browsers and a lot of people still use Internet Explorer 6 which was released back in 2001. And 8 years are quite a long time for the ever changing internet. It’s time to help people to realize that they have to upgrade. Web developers can not just keep on hacking around the bugs of IE6. In order to improve the internet (and probably help yourself) add this banner on your website.

During the browser wars, IE became the spearhear of innovation. Microsoft introduced a lot of useful features like the XMLHttpRequest which is used for AJAX. However most of the features were not changed to be compilant to the recent standards and therefore cause a lot of troubles for webdevelopers.

With the IE6 becoming the most widespread browser and clearly winning the browser wars, Microsoft stopped investing into browser technology since browsers become more and more capable of being a platform for  crossplatform application development. Innovation stalled until the rise of the open source browser firefox, the “grandson” of netscape navigator.


Work faster without GUI

The GUI was developed by Xerox PARK in 1973. Since then not much changed, we still use window, icon, menu, pointing device (also referred as WIMP). We have lot of  fancy, new features like desktop search, more colorful icons an we like, but still not much changed.

As useful as this approach might be is doesn’t scale. Ever tried to find a bookmark out of a list of thousands? Trying to find something in such a huge menu is nearly impossible. Probably it’s easier to just google for it. The point is that with 5 letters you can select from millions of possible combinations. These 5 letters you probably type in under a second.

“Wait!’ you might say “Are you saying the command line is superior to a graphical interface?”. Well, I am not. Most people fear the command line because they don’t exactly know how to do what they want to do. There is no list of options to select from (or it would be too long).  Another downside of the command line are cryptic commands like “tar -xzf”. The learning curve is step. Again take a look at google suggest to see how to improve the situation. It’s a really helpful feature to find what you are searching for quicker.

Now just imagine your could click on your file press a key and then type “tar”. The command is smart enough to realize the file you clicked is not yet packed, so it’s packing it, maybe first it suggests the name of the archive to be “some_filename.tar” which you accept by pressing enter. If you click on an tar archive, it would “know” you want to unpack it. Sounds simple? Well, it is. Still not convinced? Then try it yourself with Enso (Windows),  Quicksilver (Mac), Ubiquity (Firefox)


Suite yourself – Why the label “created by microsoft” doesn’t matter

For some time now, I am working on the windows platform again using .NET 3.5, C# and ASP.NET. With more and more functional programming elements introduced into the .NET platform such as LINQ I really prefer C# over Java.

However one thing that bothers me and is very often accountered is the sheer awe of microsoft. Every solution for a problem provided by them have to be the best by definition.

“written by Microsoft” – While this may not mean anything to you, it is significant to me. These guys probably have more development expertise in .NET than I do. I know they have more development budget than I do and probably anyone I’m ever going to work for.

Carey Cilyok

While this statement is probably true, it misses some critical points:

  1. Development of open source projects utilizes the development skills of many thousands of developers, which should even surpass microsofts budget.
  2. It doesn’t really matter how big a budget is, since Microsoft solutions are aimed for a broad market they grow and grow to suit the needs of just about anyone while open source solutions direct their development efforts at a certain target audience, hence fitting their needs better. Just take ruby on rails as an example. They created an innovative web development framework which Microsoft is going to “borrow” ideas from for ASP MVC.

As John Snyder pointed out:

The reason I like Java better, and it out weights all of C#’s advantages, is the perceived attitude of the Java community. When I look around at what is going on in the Java community I see many people working on all kinds of interesting things. There is an attitude of “Hey that would be cool, I’ll build it”. When I look around at the .NET community I get the sense that people are waiting around for Microsoft to provide all the infrastructure.

Bottomline, Microsoft solutions are quite good, but definitely the lable “written by Microsoft” doesn’t mean much. Small companies can focus more on the things microsoft missed. As a developer take Resharper or Visual Assist X as example. Once you tried it would you still like to miss it? However while some companies spend much money on upgrades of visual studio, some don’t see the benefits of investing in small tools like the above mentioned.

Sometimes we would do better if we trust in ourselfs more, since we know best what we really need. We should be able to find what suites our needs best.

Save the pixel, Save your message

What if you could make your website more successful just by tweaking it a little bit here and there instead of doing a complete makeover?

In his book “Save the Pixel” Ben Hunt explains why web design is much more then simply adding fancy images to an website, showing that design has more then one side. Focusing on the information architecture perspective Ben suggests that web designers should bring the “I’m in the right place to get what I want” message across effectively by simplifying the sites design. As a measure of success designers can use the formula “Success = Attention / Stuff” as a guideline.

The more stuff (pictures, gradients or any other kind of visual elements) you have on each page, the lower the chance that visitors feel like they’re in the right place. Every element should justify it’s existence by providing useful and succinct information, direct his/her attention or create a feeling that communicates the goals of the site. Designer should get rid of any unnecessary stuff that doesn’t serve that purpose.

Ben gives excellent tips on structuring website, be sure to visit his blog (webdesign from scratch) for high quality tips free of charge.

Improve your websites first load performance

If you are a serious webdeveloper the chances are good that you are already using one of the famous javascript-libraries like jQuery, Prototype/, MooTools, YUI or others. These libraries can be a big part of the content that needs to be send to the visitor of your website. This however don’t need to be the case as long as the site is not limit to a companies intranet.

So if you are using a piece of code like the following:

<script type="text/javascript" src="/js/jQuery.min.js"></script>

consider using the Google AJAX Libraries like this instead:

<script type="text/javascript" src=""></script>

Doing so, you are reaping 4 benefits (decreased latency, increased parallelism, better caching and less traffic) from it:

Decreased Latency:
By using the CDN (Content Delivery Network) of google you make sure that the visitor downloads the script from the closed available server belonging to google. Therefore the download might be faster and the response time shorter.

Increased parallelism:
Browsers limit the number of simultaneous connections per hostname. Depending on the browser, this limit is usually 2 or with newer browsers 6. This means for some users that while downloading 2 scripts, images, or stylesheets from your server they still can download the javascript library of your choice from google. In some cases the difference is noticeable.

Better caching:
Probably the greatest benefit of using a CDN like e.g. the Google AJAX Libraries is that your visitors may not need to download jQuery at all even on the first visit. If the visitor have ever surfed an website also using the Google AJAX Libraries, it’s highly likely that it’s already in the browsers cache. This is also a big benefit for the user, since he/she doesn’t need to have dozens of identical copies of jQuery in their browser’s cache. Also the caching is optimally configured and browser can cache the file for up to one year.

Less Traffic:
For smaller websites another benefits might be that less of the valuable traffic is actually send on sending “website internals” to the visitor. Nothing send, nothing paid.

Make your life easier with event delegation

Event delegation is a simple javascript idom that spares you from a lot of hard work. In case you have a list of items (like <table> or <li>) there is no need to start to add an event handler like onclick to every single row/list item. Instead it is enough to just add a single handler on the table/list itself.

If you ever used javascript (especially if you are using a library like JQuery) maybe you already added elements to your page retrieved by an ajax call and notice that nothing happens then you click them since you need to manually add an event handler to them. In this respect Javascript is very different to CSS. In CSS all styles get applied automatically even if an element gets added to the page later (more on the great tutorial on learning jquery). However “behaviour stylesheets” would be a really nice feature to write unobstrusive javascript.

Things get easier then using event delegation. Every time you click on a row of your table your event handling function will be invoked. The event information will be passed as an argument to it. The nice thing is that the event handling will work automatically even on newly added rows. For cross browser event handling, you might take a look at quirksmode or simply use one of the major javascript libraries. The following examples uses JQuery.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<title>js test</title>
<script type="text/javascript" src=""> </script>
<script type="text/javascript">

  $('#tlist').bind("click", function(event) {

function rowClicked(r) {


<table id='tlist' border="0">

One of the libraries leveraging event delegation is reglib. Another option might be the JQuery plugin LiveQuery and others. Starting from version 1.3 JQuery offers the methods “live” and “die” that provide some simple event delegation features.

These libraries attach event handlers to the document itself (since every element bubbles up there eventually) that choose the function to call based on the selector the fits too. Even if this is not the optimal solution for every application, I hope you consider the use of event delegation on <tables> and <li> instead of attaching an eventhandler to every single row.


REST rescues HTTP from violent developers

Then I started web development (using PHP) one of the first things I learned was the differences between GET and POST. Back then (in 1999) GET was usually described as bookmarkable, parameter-length/payload-size is limited  and post as arbitrary sized payload (parameters), not bookmarkable.

It seems that as time passed by many developers eigther completely forgot or never learned about the other verbs HTTP is offering (PUT, DELETE, HEAD, TRACE, OPTIONS, CONNECT). Instead of using HTTP as indent by the it’s makers, we added new layers on top (e.g. XML-RPC and SOAP) to practically duplicate the already build in functionality.

With the current strive for simplicity (using JSON instead of XML, Ruby on Rails instead of JSP) some developers rediscovered the Representational State Transfer (REST) architectural style. The basic ideas are simple and most of the time this functionality is exactly what we need:

  • An URI describes the location of a resource.
  • By using the correct verb in an HTTP-Request, resources can be retrieved (GET = read ) and manipulated (POST = create ,PUT = update, DELETE = delete)
  • A resource have one or more representations (e.g. formatted as JSON, XML or HTML)

Now it’s your turn to rescue the web! Use REST, use GET if you want to retrieve resources without changing it’s state and make sure that you don’t use POST, PUT, DELETE to retrieve data. Oh, and it might also help to take a closer look an HTTP itself. Try to log some of your HTTP-traffic while surfing using a tool like wireshark and see yourself what is actually send. Some of the information (e.g. Content-Type, Cache-Control, Content-Language) might be really useful then developing a nice web application.

Further reading on this topic: