Timeline for Unit testing, testing internals
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 19, 2021 at 11:41 | comment | added | David Arno | @KilianFoth, "Why would you not change a class for the sake of a test?" An example is when someone makes a private method, public, because they want to test it. There are cases where it's the test that needs changing (eg to test via the public API) rather than the code needing changing. | |
| Nov 18, 2021 at 13:27 | vote | accept | Wballer3 | ||
| Nov 18, 2021 at 11:14 | comment | added | Kilian Foth | Why would you not change a class for the sake of a test? Either the tests have business value (in that they help you create a defect-free deliverable) - then there is no reason to treat them as second-class code. Or they don't add business value - then there is no point in having them in the first place.. | |
| Nov 18, 2021 at 10:39 | answer | added | David Arno | timeline score: 2 | |
| Nov 18, 2021 at 10:09 | comment | added | Filip Milovanović | Injecting a timer offers some flexibility - allowing client code to select a suitable timer implementation: a timer with specialized behavior, or of a different resolution, or one that can stretch or compress time (e.g., could be useful in a game), etc. 2/2 | |
| Nov 18, 2021 at 10:09 | comment | added | Filip Milovanović | "then it feels like I am adapting my class to the test" - if you shift your perspective, and think of the test not as just a test, but as a preliminary/experimental example of client code that's going to use your timer (a stand in for the actual, production client code), then tests let you define/explore the different ways the timer can be used (you can design how flexible or constrained you want this to be), and "adapting to the test" is then, really, adapting to different usage scenarios. 1/2 | |
| Nov 18, 2021 at 9:47 | history | asked | Wballer3 | CC BY-SA 4.0 |