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?


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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