I’m a junior programmer near to my 6 month probation, following my initial career changing 3 month assignment in which I added TDD tests and wondering whether I should add tests to my current work. The senior programmer says I can if I want but he hasn’t, but he does wants me to document the system whilst I’m learning it.
The system is a large MVC web service of 90 pages which utilizes a number of technologies young and old, for instance the project has been migrated to MVC 5, uses a DAL generator written in house in VB.net, and has code in the Unit of work design pattern amongst others It has been worked on by many programmers over a number of years and providing my code works I can do what I want.
My question really is, should I add TDD Yes on No.
8
TDD isn’t about debugging, it is about proving the code functions as expected. Strictly speaking, the tests should have been written before the code but you are where you are.
Unit tests benefit future developers since failing tests should raise a red flag that they’ve inadvertently broken something and should attend to it.
That isn’t to say there is no value in retro-fitting the tests – there certainly is, but it may be less straight forward as you’ll be venturing into potentially obscure and rarely touched code.
Automated unit tests and TDD in particular are a complete sea change from previous practices so you’ll no doubt encounter some resistance. The fact that your senior programmer doesn’t see their immediate value speaks volumes.
The takeaway point is to understand that you’ll be adding value to the system, so don’t feel too discouraged if nobody else takes up the baton or various tests are parked when they fail etc.
5
Adding unit testing to a project in retrospective is usually more pain than it is worth. There is a reason why the red/green/refactor workflow mandates to write the tests first and the code which passes them afterwards.
In order to be properly testable, the whole code architecture must be designed with unit-testing in mind. You need to follow patterns like dependency injection, separation of concerns and loose coupling. When such patterns were not followed thoroughly during developing (and considering that you are talking about an old legacy project developed by many different people with different methodologies they likely were not) the code will often require large-scale refactoring before meaningful unit-tests are possible. These refactorings would take a lot of time and carry a high risk of introducing new bugs.
However, if you really want to apply your TDD knowledge, you could try to apply it to any new features you implement.
2