CODEWITHSUNDEEP
unit-testingtdd
Dan Rosenstark
Dan Rosenstark

Reputation: 69777

Unit-tests for a working codebase with limited time: How?

I have a few medium-sized Rails apps that I work on routinely, and only one of them has any unit tests at all. But I have seen the light and I want to change all that, except... I don't have the time to go in and starting writing tests class by class or something like that.

How do you start writing unit tests on an existing -- and working -- codebase with limited time? For example, since any approach would have to be incremental, how would you order your unit-test writing? Start with superficial tests, then move on to more coverage, or cover just a few classes... etc.

Note: I am asking this question thinking about Rails, but really I'm interested in how it applies to any language.

Edit: Note, this question is not the same as this other one. The other one asks how hard this is, and was the result worth it. I'm asking about how to add unit tests.

Upvotes: 9

Views: 406

Answers (7)

Arnis Lapsa
Arnis Lapsa

Reputation: 47627

With limited time? Facing deadlines?

Forget about unit tests!

Cowboy coding 4 the win!

Hack features together until it's not too late and client haven't sued Your company.

P.s. For your own safety - do not forget to inform about situation your PM.

Strange that down votes avalanche haven't started yet. Maybe it's not so bad and telling NOT to write unit tests ain't such a taboo at all.

I'm in similar situation (assuming Your time is really limited). What i do - i don't think about unit tests most of the time. But for some cases - it's actual easier to do TDD than to continue hacking (emm... duct taping? :D ) everything together (usually when testable unit has high complexity or is hard to test manually), then i just switch my mind and code normally. In short term - i will be able to understand what i wrote month ago and that won't make much trouble. Problems will arise when project will slip into maintenance phase. But it's still way much better than telling client that you worked on tests and got nothing new.

When you need to start unit testing in existing project - start with your own functionality. Create necessary test infrastructure (if time allows - continuous integration too) and don't forget to teach unit testing to your co-workers.

Worst thing you (or PM) can do - to force writing unit tests to someone who does not know how to do that. That's just wasting time. Lead by example. Gradually.

It did start after all! ^_^

Upvotes: 0

Tyler
Tyler

Reputation: 869

I had a very similar experience a few years ago, and stumbled upon this book:

Working Effectively With Legacy Code by Michael C. Feathers

It has an incredibly complete set of techniques for starting with an existing codebase that has no unit test coverage, and gradually getting it under test. If I could recommend only one book on TDD, it would be this one.

Hopefully this helps... best of luck!

Tyler

Upvotes: 5

Dean J
Dean J

Reputation: 40348

In the long run, unit testing should make getting (working!) functionality to the users faster.

If it's not accomplishing that, it's not worth the time.

Upvotes: 0

Otávio Décio
Otávio Décio

Reputation: 74290

One of the problems I faced when I started writing real unit tests (with mocks and etc) is that I had to go back and change the code to support the injection of the mock objects mostly through the extraction of interfaces. I believe it will be pretty hard for you to do that on an existing system without some sort of refactoring.

Upvotes: 2

user23743
user23743

Reputation:

My answer isn't specific to Ruby on Rails. Next time you need to touch the codebase, to fix a bug or add a new feature, write tests for the parts of the code you're touching. If you can spare a couple of minutes, add some related tests. If you find that you need to refactor, go ahead and write the tests to support that. Over time you'll build up the test coverage, and you'll find you always have tests for the areas you need them in (because those are the tests you're writing).

Upvotes: 5

James Kingsbery
James Kingsbery

Reputation: 7496

Here is how I usually start adding unit tests to a project that didn't start out that way: Wait for someone to file a bug, then write a unit test that reproduces the bug. Then fix the unit test. This not only starts building unit tests, but now no one can accuse you of a regression for the given bug.

Upvotes: 10

Paul Creasey
Paul Creasey

Reputation: 28864

Increasing code coverage is an excellent way to get a new recruit familiar with a codebase.

Other than i think you just need to find time, there is no magic solution!

Upvotes: 0

Related Questions