Timeline for How do you square TDD with non-testable requirements?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 14 at 10:33 | history | protected | gnat | ||
| Jul 29 at 13:14 | history | edited | candied_orange | CC BY-SA 4.0 |
added 41 characters in body
|
| Jul 29 at 3:37 | answer | added | user449120 | timeline score: 0 | |
| Jul 28 at 20:19 | answer | added | candied_orange | timeline score: 4 | |
| Jul 27 at 20:48 | review | Close votes | |||
| Aug 1 at 3:06 | |||||
| Jul 27 at 16:11 | comment | added | freakish | When people talk about TDD most of the time they think about testing runtime behaviour. However it most certainly is possible to test the code design itself up to a certain level. That's what static analyzers do all the time. However to fully enforce things like clean design is simply not possible technically. Such static analysis is just too hard I think. For example: how can I write a test that checks that a class does only one thing? That's not even formally well defined. | |
| Jul 27 at 14:00 | vote | accept | Sergey Zolotarev | ||
| Jul 27 at 13:47 | comment | added | amon | Two remarks beyond Greg's observation that TDD implies a refactoring phase: (1) Robert C Martin has opinions, and many of them aren't that good. Clean code is a great marketing term, but Martin doesn't do a great job of explaining when good is good enough. By explaining concepts via teachable slogans, nuance is lost. (2) You can make a lot of aspects automatically checkable via linters and static analysis, for example variable naming schemes or a method's cyclomatic complexity. That's not a test in the TDD sense, but has equivalent developer experience. | |
| Jul 27 at 13:21 | answer | added | Greg Burghardt | timeline score: 11 | |
| Jul 27 at 13:03 | history | asked | Sergey Zolotarev | CC BY-SA 4.0 |