1

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.

Improve this question
8
  • 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 Commented Feb 3, 2016 at 14:29
  • 1
    Possible duplicate of Do I need JUnit tests for the controller layer on a MVC when I have a database layer Commented Feb 3, 2016 at 14:30
  • 1
    "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 Commented Feb 3, 2016 at 15:42
  • 2
    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. Commented Feb 3, 2016 at 16:20
  • 4
    You are intermixing the terms "TDD" and "Unit tests". Commented Feb 3, 2016 at 17:01

2 Answers 2

Reset to default
3

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.

Improve this answer
5
  • 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. Commented Feb 3, 2016 at 15:27
  • 2
    You are intermixing the terms "TDD" and "Unit tests", just as the OP. Commented Feb 3, 2016 at 17:01
  • @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. Commented Feb 3, 2016 at 17:07
  • 1
    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. Commented Feb 3, 2016 at 17:19
  • @DocBrown Fair enough - I've tidied my answer a little. Commented Feb 3, 2016 at 17:39
4

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.

Improve this answer
2
  • +1 You can't just casually waltz into legacy code and start writing unit tests. OP should first evaluate the drawbacks. Commented Feb 3, 2016 at 15:56
  • 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. Commented Feb 3, 2016 at 17:29

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.