Skip to main content
replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
Source Link

These days, it's fairly common for me to be tasked to make a change that actually breaks the prior spec. I know that one of the major ideas behind TDD is to have a suite that verifies all your changes didn't actually break anything, but what do you do when the change you need to do, by it's very nature, actually must break the unit test?


http://programmers.stackexchange.com/q/262944/53019How to do Test Driven Development is a similar, related question but it is subtlety different from my question. In my case, I already have the test and the specification has changed. In that question, the OP does not have the test yet.

These days, it's fairly common for me to be tasked to make a change that actually breaks the prior spec. I know that one of the major ideas behind TDD is to have a suite that verifies all your changes didn't actually break anything, but what do you do when the change you need to do, by it's very nature, actually must break the unit test?


http://programmers.stackexchange.com/q/262944/53019 is a similar, related question but it is subtlety different from my question. In my case, I already have the test and the specification has changed. In that question, the OP does not have the test yet.

These days, it's fairly common for me to be tasked to make a change that actually breaks the prior spec. I know that one of the major ideas behind TDD is to have a suite that verifies all your changes didn't actually break anything, but what do you do when the change you need to do, by it's very nature, actually must break the unit test?


How to do Test Driven Development is a similar, related question but it is subtlety different from my question. In my case, I already have the test and the specification has changed. In that question, the OP does not have the test yet.

Tweeted twitter.com/#!/StackProgrammer/status/545698241078374400
added 266 characters in body
Source Link
user53019
user53019

These days, it's fairly common for me to be tasked to make a change that actually breaks the prior spec. I know that one of the major ideas behind TDD is to have a suite that verifies all your changes didn't actually break anything, but what do you do when the change you need to do, by it's very nature, actually must break the unit test?


http://programmers.stackexchange.com/q/262944/53019 is a similar, related question but it is subtlety different from my question. In my case, I already have the test and the specification has changed. In that question, the OP does not have the test yet.

These days, it's fairly common for me to be tasked to make a change that actually breaks the prior spec. I know that one of the major ideas behind TDD is to have a suite that verifies all your changes didn't actually break anything, but what do you do when the change you need to do, by it's very nature, actually must break the unit test?

These days, it's fairly common for me to be tasked to make a change that actually breaks the prior spec. I know that one of the major ideas behind TDD is to have a suite that verifies all your changes didn't actually break anything, but what do you do when the change you need to do, by it's very nature, actually must break the unit test?


http://programmers.stackexchange.com/q/262944/53019 is a similar, related question but it is subtlety different from my question. In my case, I already have the test and the specification has changed. In that question, the OP does not have the test yet.

Source Link
durron597
  • 7.6k
  • 10
  • 38
  • 67

Test Driven Development when the specifications change

These days, it's fairly common for me to be tasked to make a change that actually breaks the prior spec. I know that one of the major ideas behind TDD is to have a suite that verifies all your changes didn't actually break anything, but what do you do when the change you need to do, by it's very nature, actually must break the unit test?