Test Driven Development

Test Driven Development

What is Test Driven Development?

TDD is one of the many ways of thinking about the logic while programming. There are also aspects to think about like – Object Oriented Modeling of the Software Modules and Layers, handling platform and library specific dependencies, making the programming code easier for change, update, adapt to ever changing specification requirements, make the source code easier to separate and delegate functionalities to different developers and so on. There are endless things to think about. But one of them is thinking as – how to develop functionality and test it – even before implementing it.

Test Driven Development guidlines – to wrap how the functionalities should work – even before they are coded. First the programmer should implement nad verify the “happy path”– does the code works when all the parameters are correct, then there are the endless variations of wrong or invalid inputs that – if placed in the tests – will verify until the end of the existence of the software – does the software behaves correctly on every type of input, after every change.

For what areas is Best Suited

Tests are a good thing to have in whatever type of project, but, there are certain projects that are better suited for having tests.

Some of them are implementations of technical standards that are negotiated between organizations, that are used by millions of people and are changed less often – after another long negotiations. Other place are the software owned by countries – guided by normative requirements and laws. The process of changing such requirements is again – or it should be – a little bit less often and with some time of notice.

In financial institutions – having tested repeatedly, frequently, deeply – the software that handles money is very important in area where everything is math and it “touches” the pockets of millions and billions – literally.

Life endangering areas – medical software, devices that measure health conditions and so on.

Engineering – A lot of the life endangering places are actually in engineering – automotive industry, aviation, bridges, road building, simulations, calculations. One bad math in such areas could cause a lot of direct deaths and indirect life endangering incidents and problems.

There are also cases where having tests is going  to extend the development time and will not make developers, testers, managers and the whole team Рnot happy. These cases could be Рstat-ups that do not know what a software should do Рwith fast charging upside-down requirements. The development approach that is shortly named Рagile is also a chance to create total mess in the development Рwith changes of the requirements over night.

The biggest factor if TDD is a good idea – if the changes of requirements is too frequent. In General – It is not developer problem to figure out requirements. But when they change – it becomes increasingly a developer challenge to keep up – make the clients happy and keep the functionalities wired together and not breaking.

Several points of view on TDD from different roles.


The managers may not be happy about that the software development may take longer. They may need to convince clients or/and investors when things are not actually done fast enough. They may take less money (which I don’t believe) from the work because of the greater development time. But, All the senior roles will be happy in the long run, because of the higher quality of the software. Even after the lower level developers leave and change over time, the newcommers will have a harder time to break things unconsciously and because of the written and unwritten guidlines of all the legacy code, the fresh developers will probably continue with the practices in the code and will make indirectly – the clients and the users happy because of the lack of bugs and probably – paying – so managers will be happy.

Quality Assurance Specialists

If there are tests in the code, written by the developers, it will be harder for the tester to find bugs. If the Quality Assurance Specialists code testing scripts themselves (automation testing), they may be slower at the very beginning, but as their scripting base grows, they will detect bugs faster and with less actual work – just rerunning the old scripts.


It depends – how the coder will feel about TDD, from the project type, development cycle, the experience of the software engineer and so on. The developer may not be happy of TDD because it the work will take more time as a number of lines. If the requirements change, this means changes in the code in two (or more) places.

Besides the project type and the software organization environment, should the developers choose TDD has some other factors.

Ego, delusion of competence. When a developer adds some projects in the bag, he starts to become confident about his skills. The thing is – his own code is not the only variable in the software product quality. There are code library changes, operating system and environment updates, IDE improvements, misconfigurations, cached code, programming language changes. The custom code on the top – the developer’s code is just the tip of the iceberg.

The Idea of TDD is to never trust your own code, and let it verify itself instead of rerunning and clicking endlessly like a monkey. One other good aspect is placing the edge cases in the tests – adding them to be verified as well as the happy path – each time you encounter them is a must and rises the quality a lot. This way – there is a lot less need to have a QA/tester to check and verify your code changes every day.

If the coder is paid per hour basis, probably he will not care about the longer hours and he may be actually happy – to have one more task that will require time and get paid for, thus extending development because of getting paid per hour instead of per task.

More time writing code? Normally a developer tests his own code before pushing it to be tested by others (QA/Users). When the code includes User Interfaces, he/she must run it on the planned platform – console, browsers, native mobile phone or desktop computer, some simulator or emulator. REST client tools that are often used when a software doesn’t have a UI. To test an app that is executed as console command – there are console prints/writes. If a test code is placed during development – all stuff could be executed automatically by the building/package process/program. If the requirements jump a lot, this will require changes in the test cases and this will make the programming waste more time. In such cases fast – hacky coding may make clients happer. It all depends.

Leave a Reply

Your email address will not be published. Required fields are marked *