I've been doing TDD with a project I'm working on, and I have quite a large number of tests.  I have quite a few automated tests around restrictions enforced in code, making sure things that shouldn't be allowed aren't allowed.  Now I've been told that due to changes in our licensing model, some of those restrictions need to be removed.Since I've done the entire project using TDD, I'm not sure how to make a change like this also using the TDD mindset.So, my question is: Do I make the back end changes and see what tests break, or do I try to find the tests that enforce the behaviour, and change those first?My concern is that if there are operations A, B, C and D where a check is done to disallow the behaviour, and I have equivalent tests TestA, TestB, TestC, and TestD (possibly in different places) no matter which half I change first, I may miss one or two spots and end up with incorrect behaviour, but still have all the tests pass (e.g. what if I miss TestD?)
How do I do TDD when expected behaviour is to be changed?
tdd;refactoring
Having done the entire project with TDD, I'd advise you to stick with it.  Many requirements are changing, but take them one at a time.  For a new requirement, either write a test for it, or find the existing test that should now have different results.  Change it to correspond to the new requirement, and watch it turn red.  Now make it pass.  When you make it pass, you might find another test (or tests) breaks, because that test depended on the old behavior.  That's fine.  Review the breaking test and ensure that you haven't really broken behavior (if you have, undo your change).  Update the breaking test to correspond to the new desired behavior, and watch it turn green.  Repeat until done.