Timeline for Should we always unit test bugs when correcting them?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 10, 2012 at 19:11 | comment | added | Peter K. | +1 for "since interruptions to run down bugs tend to have more overhead than simply developing and maintaining a unit test." | |
| May 10, 2012 at 18:57 | comment | added | Old Pro | I would also favor generalizing the test so that it's not just testing aborting and retrying the job when it reaches one specific state, but rather tests aborting and retrying at every state a job could be in. | |
| May 10, 2012 at 17:31 | history | edited | Telastyn | CC BY-SA 3.0 | deleted 2 characters in body |
| May 10, 2012 at 17:31 | comment | added | Zonko | well, indeed, in the end it's all about a balance between the time needed to maintain the test vs the time it would take for a noob to detect and correct the bug if it happened again. | |
| May 10, 2012 at 17:24 | vote | accept | Zonko | ||
| May 10, 2012 at 17:23 | comment | added | Joshua Drake | I would add more emphasis to this and state that in an ideal world it would only be considered a bug if a failing unit test exists, but +1 for the italics and noting that business needs should prevail. | |
| May 10, 2012 at 15:20 | history | answered | Telastyn | CC BY-SA 3.0 |