Timeline for How to keep unit tests well designed when structure of production code changes while avoiding related risk?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 17, 2016 at 8:30 | comment | added | kamilk | Maybe it is the best solution. But normally I would try to follow TDD in writing failing tests first, which validates they test the right thing. Here I wouldn't have this stage. I currently have tests likely written in this manner but I would be discarding them in favour of tests which would pass as soon as they are written (I've already done the refactoring). Though maybe I'm exaggerating the risk? | |
| Oct 17, 2016 at 7:02 | comment | added | Euphoric | @kamilk But I don't think can replace the whole test suite safely. How so? It doesn't matter if you change code or tests. If both coraborate, then everything is fine. | |
| Oct 17, 2016 at 6:39 | comment | added | kamilk | I didn't say there was anything else I wanted to improve in the production code. But as a result of refactoring I ended up with a class structure for which I would normally write very different unit tests. But I don't think can replace the whole test suite safely. | |
| Oct 17, 2016 at 6:19 | history | undeleted | Euphoric | ||
| Oct 17, 2016 at 6:18 | history | deleted | Euphoric | via Vote | |
| Oct 17, 2016 at 6:15 | history | answered | Euphoric | CC BY-SA 3.0 |