Other articles

  1. Pulling the Plug on Date Time Parsing

    Date/time logic is hard. Throw in time zones along with daylight saving and it's even harder. Recently a suite of tests that had happily been running for months started failing. There were no code changes and all the tests were somehow related to date/time ranges.

    Despite this the …

  2. Write Assertions First

    Writing a test as part of the TDD process is simple.

    1. Arrange
    2. Act
    3. Assert

    Many individuals recommend the process be reversed. Write assertions first. Then write the steps to perform the action. Followed by the required setup to complete the action.

    1. Arrange
    2. Act
    3. Assert


    You will write just enough …

  3. Types of Test Doubles

    Mock is an overloaded term in software development. Sadly this leads to developers answering with "mock it" when a mock object may not be the right solution. Test Doubles are a more general term. I should try to use this naming more than I do at present - a goal I …

  4. Why I Don't Like Mocking Frameworks

    Disclaimer: By mocking framework I generalize anything that includes support for stubs and mock objects.

    The use of mocking frameworks was a difficult part of my TDD journey. Not only are newcomers expected to get their head around the basics of the practice there are now new tools to contend …

  5. Integration Tests

    It is well documented you need a balance between different categories of automated tests. The split is usually in the form.

    • 70% unit
    • 20% integration
    • 10% acceptance

    While unit tests make up the majority of tests, there is a limit to their effectiveness. As soon as you leave the system …

  6. You Still Need Manual Tests

    This blog has numerous examples of why unit, integrationand contracttesting is essential. However you still need manual tests. It is foolish to believe that all testing can be covered by automated tests despite the bias in this area.


    • Manual tests can catch anything you may have missed …
  7. Testing Private Code

    A common problem many people ask is - should you test private code? In short, you shouldn't. You should always test the public api of your code where possible. This is not always easy. Based on the context of the code in question there are a few options available.

    Don't Test …
  8. Randomly Generated Values in Tests

    The use of randomly generated test data seems like a good thing at first glance. Having worked with several teams that have used this concept I generally discourage the practice. Consider a simple method that joins together two strings. A test using random values may look like this.


    Harder …
  9. Factory Obsession

    I have noticed a pattern over the years with developers of which I will refer to as factory obsession. Everything is a factory or builder object. To some, the use of new is banned.

    Consider a object that is responsible for some business logic and finally saves the result to …

  10. Achieving more Isolated Unit Testing

    Good unit tests should be:

    • fast
    • independent
    • well focused
    • isolated

    If your unit tests are slow, you're not gonna run them as often as you should. Therefore one of the main benefits of unit testing is lost - the lack of instant feedback.

    Each of your unit tests should be independent …