Change in business is inevitable. Changes in laws, market forces, and business strategies are regular occurrences. Resistance is futile. Instead, application developers need to learn to embrace change. The correct and dedicated practice of TDD will give your application an advantage by making it more flexible and adaptable for change.
When you're working with a new feature, you must employ the same business analysis, design, and estimation protocols that were used to develop the application. This is true even for applications that have already shipped or been deployed to production. Do not fall into the trap of cutting corners under the claim, “Well, it's just a small change.” Even small changes implemented poorly can severely damage an application and customer trust.
Whether you're working with a new feature or a defect, the first step in the development process is the same: writing a test. This test should initially fail. If this test passes, some investigation is required. Does your test test for the correct functionality or defect? Are you testing the right part of the application? Does the newly requested functionality already exist as a side effect of some other functionality? Remember that just because a test passes immediately doesn't mean that you have fixed the defect or that the new functionality exists in the application.
After your new test is written and you've seen it fail, the steps are the same as when you're doing primary development of the application. ...