Should a Junior programmer add TDD tests to mvc project

Question

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.

• Andrew Day: There are some old tests, but I would need to slowly go through them and rehash most from what I can see. Is there a good framework for MVC testing
• gnat: Possible duplicate of Do I need JUnit tests for the controller layer on a MVC when I have a database layer
• gnat: "My question really is, should I add TDD now on basic logic for the controllers and build it up" - that was prior to recent edit. As for the edit, see Question closed because yes/no answer
• Jörg W Mittag: I'm having trouble understanding what it is you are asking. What does it even mean to "add TDD tests to an existing project?" You can't add TDD tests later. That's exactly the wrong way round. You write tests first and then add the code later.
• Doc Brown: You are intermixing the terms "TDD" and "Unit tests".

Answer 1

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.

• Andrew Day: Previously I had added tests before the code so aware how important that habit is... @Robbie I agree whole heartedly with your answer, and thank you very much for the advice.
• Doc Brown: You are intermixing the terms "TDD" and "Unit tests", just as the OP.
• Robbie Dee: @DocBrown To be clear - retro-fitting unit tests isn't TDD, but it does deliver value if done correctly. As outlined in Philipp's answer, it is by no means straight forward.
• Doc Brown: Did I wrote something different? I am just saying you are using the terms wrong, just as the OP. Someone should tell the OP he is not adding "TDD tests" to the project, that makes no sense.
• Robbie Dee: @DocBrown Fair enough - I've tidied my answer a little.

Answer 2

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.

• Alternatex: +1 You can't just casually waltz into legacy code and start writing unit tests. OP should first evaluate the drawbacks.
• Robbie Dee: Adding tests to an existing code base is certainly possible to a degree without the extensive surgery that DI et al can require. Beyond this, it is a judgement call whether the potential benefits outweigh the refactoring risks. Unless you have a considerable degree of latitude with the code base, you're more often than not stuck with the lower risk lower benefit approach in my experience.