Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Say I have a class with a single constructor that accepts 2 parameters and initialises itself using those parameters. I have written tests for this and they are all passing.

I later realise I need to make an addition to the constructor to accept three parameters. Should I

a) Add in the new parameter, watch my tests break and try and fix it

b) Rewrite existing tests to test for the new expected behavior, watch them initially fail and then add to the class (this to me seems a more TDD way)

From a TDD point of view, I think that option 'b' makes more sense. However, option 'a' (to me) seems like a more natural approach.

Is there any standard way that most people do this?

share|improve this question
up vote 9 down vote accepted

Obviously, TDD says you should do (b).

Changes in method signatures pose the complication that in many languages the tests won't actually fail - they won't even compile! It is a matter of opinion whether this constitutes a 'failing' test for which, according to the strictest kind of TDD, you are allowed to write new code.

But the point of TDD is really to check that your API makes sense before programming it. If you have to change a lot of tests to add a parameter, you may notice that this is cumbersome, that it would be better to create a compound object for some of these parameters, or that you do need to be able to create objects without the new parameter after all! This is the real value of TDD (as opposed to merely guaranteeing test coverage), and that's why I would say go ahead and revise your tests first.

share|improve this answer

I guess what is more natural depends on whether you are a test driven developer or a test last developer.

Quoting "Growing Object-Oriented Software, Guided by Tests" (Steve Freeman, Nat Pryce), the golden rule of TDD is: Never write new functionality without a failing test.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.