Timeline for Unit Testing - should / how should I write tests to cover new code that doesn't affect the interface of a method?
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 4, 2023 at 18:08 | comment | added | gnasher729 | Should mention: "... or there are no obvious deficiencies", meaning all deficiencies are hidden in a snakes nest of impenetrable code. | |
| Dec 31, 2022 at 9:45 | comment | added | gbro3n | Thank you, for your answer. Regarding Robert C. Martin's comment, I've found in SE that there are few absolute rules, but when I come across statements like these from authors of his calibre, I need to check that I'm not missing some insight. Your answer articulates my intuitions well. | |
| Dec 30, 2022 at 19:44 | comment | added | Filip Milovanović | I like this answer and the practical concerns it addresses, but I'd also like to point out something, just so that there's no confusion: Hoare does start with "One way is to make it so simple that there are obviously no deficiencies [... the other is to overengineer (paraphrasing)]", but continues with "The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature." So, he's not talking about doing it the way that initially seems the most straightforward. | |
| Dec 30, 2022 at 18:00 | history | answered | VoiceOfUnreason | CC BY-SA 4.0 |