Dataworks Blog


  • Test Driven Development – Unnecessary Overhead?

    At a first glance TDD can seem to be an overhead that developers could do without. The idea of writing more code to verify the code providing the functionality could be viewed as a non-productive or non value added activity for developers. Primarily a developer’s focus should be on writing code and not testing.

    It is challenging enough to deliver software on time, without focusing on writing and running tests. While this is largely true on the face of it, SDLC Methodologies have evolved from the waterfall approach to more dynamic prototyping such as RAD, Extreme programming and Agile methods.  Traditionally we followed the cycle of requirements gathering, design phase, coding, and then test and fix phase. With this approach the requirements gathering and design phases occur before a single useful line of code is produced.

    Depending on the size of the project this can mean months of documentation before any prototype of the system exists to help drive discussion and requirement refining. The coding phase is then followed by a test and fix phase where test scripts would be executed against the agreed requirements. This methodology may suit certain projects, but there are some obvious disadvantages of approach.

    It can be difficult to define all requirements in detail at the beginning of the project. A lot of time may be taken up in the first two phases without any system functionality being produced. When the system takes shape in the coding and testing phases some requirement clarifications will probably occur and at this stage the cost of change will be very high. It is for this reason that the Agile approach may be more beneficial, and ultimately cost effective. 

    The more iterative approach of agile development can involve these same phases but they are repeated over several iterations with each iteration providing an agreed set of working features. TDD fits very well into the agile methods of software development where the output of each phase must result in a solid, dependable, functional piece of software. It also helps build confidence when moving from one agile phase to the next as existing tests can be executed at the click of a button to ensure modified code still works as expected. Suddenly, the initial perceived overhead or non productive activity suddenly starts to make sense, and may even save time.

    TDD Approach 

    The key to performing TDD successfully is to keep it simple. Write simple tests and code in straight forward verifiable steps. Focusing on these small specific areas of functionality will gradually result in the overall solution having well structured code with a suite of tests. 

    Advantages provided by TDD:

    Tests can be written before the code which can give the programmer a clearer understanding of what is required by the code. This also encourages good code design as methods should be simple.

    • Tests developed are as useful as documentation and a design tool as much as a testing tool.
    • Complicated debugging time will be drastically reduced.
    • Assures you that the code does what it was expected to all of the time.
    • Many frameworks exist for most software languages. (nunit for, junit for java etc) These frameworks can be built in to your IDE and provide quick and regular execution of your tests.
    • Tools exist to report the test coverage that is being achieved by your tests
    • The tests can prove invaluable for regression testing if and when modifications are required. The reassurance that these tests provides allows a different developer to be confident that any modification that they make will not have broken existing functionality



    So let us address the initial concerns we highlighted in the beginning of this article,

    It takes too much time to write the tests.

    There is an obvious advantage to fixing simple bugs found by testing early in development versus fixing complex bugs unveiled by testing executed after development has been complete.

    It takes too long to run the tests.

    If there are performance issues with some tests then these can be grouped and run less frequently (e.g. Once a day). The majority of tests will be quick and can still be executed frequently.

    It’s the developer’s job to write the code, not to test it.

    It’s the developer’s job to write clear, high quality, working code.

    TDD does need to be learned and practiced. However, there is no doubt that great efficiencies can be made by developers that put in the initial effort, and this will lead to reduced lead time on projects, more robust code and ultimately lead to cost savings. 

  • Back to Blogs