Timeline for How do you square TDD with non-testable requirements?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 28 at 23:45 | comment | added | Flater | @user1937198: All test suites should inherently come with a label that says "amend this suite when the future shows you its imperfections". It's not realistic to expect to cover every possible test scenario, nor deterministically prove that you have done so. All you can do is cover it as best as you can think of (time-effort balance), and then if you bump into any gaps later on, patch those up as you go. It's not about never making a mistake; it's about not making the same mistakes a second time (i.e. because after the first time, you should fix your test suite to now be wise to it) | |
| Jul 28 at 23:41 | comment | added | Flater | @SergeyZolotarev I think you're blindly assuming that one must have one single ideology that must encompass everything that is important. This is not true. For example, TDD does nothing to promote code readability, change-friendliness or any kind of internal implementation design. However, that doesn't mean that TDD is explicitly telling you that those things don't matter, it's just not related to what TDD is talking about. You shouldn't be developing a TDD-only codebase. You should be developing a codebase using TDD principles alongside any other principles that matter to you. | |
| Jul 27 at 18:16 | comment | added | Greg Burghardt | @user1937198, I wasn't suggesting a concrete requirement is out of scope. I was saying if all you have is "robust" and nobody can come up with a concrete metric to hit, then it would be out of score. Let me update my answer to generalize it a little more. Basically the issue seems to be rectifying TDD and non-functional requirements then? | |
| Jul 27 at 17:34 | comment | added | Sergey Zolotarev | Yes, it was an example | |
| Jul 27 at 15:23 | comment | added | user1937198 | @GregBurghardt how about a more concrete requirement of a service: must maintain 99.99% uptime. That's a clear requirement of the system, yet somehow that needs to be translated into how the software is written and validated. Just saying that's out of scope isn't very useful. | |
| Jul 27 at 15:13 | comment | added | Greg Burghardt | @user1937198, you can test for robustness provided you have specific technical specs to hit. When given a requirement like "make sure it is robust," ask follow up questions to define what robust means in that context. Now you have requirements to test. If they cannot define what robust means, then you decide what it means, and write tests to that effect. Or ignore the robustness requirement completely, because nobody knows what it means, which renders this question moot. | |
| Jul 27 at 14:59 | comment | added | user1937198 | There's also other requirements that are challenging to test, like robustness. It's easy to test that for a specific failure case, that case is handled. Its effectively impossible to test that all failure cases are tested for and handled. | |
| Jul 27 at 14:40 | history | edited | Greg Burghardt | CC BY-SA 4.0 |
added 329 characters in body
|
| Jul 27 at 14:27 | comment | added | Greg Burghardt | Or am I focusing too much on clean code, and you were just using clean code as an example of a non-testable requirement? | |
| Jul 27 at 14:23 | comment | added | Greg Burghardt | @SergeyZolotarev: I had posted a couple of comments responding to what you said, but I added that information to my question beginning with the third paragraph. Does that help? | |
| Jul 27 at 14:23 | history | edited | Greg Burghardt | CC BY-SA 4.0 |
added 946 characters in body
|
| Jul 27 at 14:09 | comment | added | Sergey Zolotarev | For one thing, there's no chance in hell you can make a robust test suit for GUI. You will always have to check it with your own eyes. Though, I guess, that is a test in a sense | |
| Jul 27 at 14:05 | comment | added | Sergey Zolotarev | Thank you. However, even with RGF, TDD makes an assumption that the only non-testable requirement is code cleanness. Which isn't necessarily the case. It could be called "red, green, refactor and do everything else that isn't testable but should be done nonetheless". But it's not what the motto says. So there's still the gap between TDD and meeting all the requirements | |
| Jul 27 at 14:00 | vote | accept | Sergey Zolotarev | ||
| Jul 27 at 13:21 | history | answered | Greg Burghardt | CC BY-SA 4.0 |