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 Ia) Add in the new parameter, watch my tests break and try and fix itb) 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?
When changing a class/method and you already have passing unit tests, should you change then test or write a test then change?
unit testing;tdd
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.