Timeline for Encapsulation dilemma: should age operations depend on external dates outside the object?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 7, 2022 at 14:24 | comment | added | Barmar | @Voo Not just tests -- when the Multics emulator was finished, the system wouldn't boot because the Multics kernel had a sanity check on the clock (there's no hardware RTC, the operator has to enter the time when booting), and it was well past that date. | |
| Apr 6, 2022 at 21:46 | comment | added | supercat | Instead of passing the date as a parameter, I'd favor passing a callback that returns a date. This will make it possible to test sequences of operations to ensure reasonable behavior if the current date changes between them. | |
| Apr 6, 2022 at 14:37 | comment | added | Voo | @Barmar Yes when writing integration tests, mocking is generally not the way to go. For integration tests you usually set up the environment (database, external REST calls,..) in such a way that you get the wanted scenario. Which probably means that the GetCurrentAge at the top-level is fine and you set up the user's age itself in such a way to exhibit the wanted behavior. Date/Time behavior and integration tests are often a source for buggy tests though, that's true (who has worked on a legacy system that didn't have tests that failed years later due to some hardcoded value?) | |
| Apr 6, 2022 at 14:21 | comment | added | Barmar | @Voo I'm referring to testing the entire application, which means testing the caller that passes the date in as the parameter. But if this is just a library, maybe that's not your problem. | |
| Apr 6, 2022 at 14:18 | comment | added | Voo | @Barmar At one point your test will call the top-level function which takes the Date as a parameter and there you can pass whatever date you want in. | |
| Apr 6, 2022 at 14:17 | comment | added | Barmar | Doesn't this just push the problem back to how we test the caller? Eventually you have to reach a function that uses the current date, and you'll need to mock the function that gets the date. | |
| Apr 5, 2022 at 23:26 | comment | added | Mark | The practical reason for passing the date is to ensure the date is consistent. Consider: you start an operation just before midnight, and the log routine generates its own just-before-midnight timestamp. The clock ticks over, and the "is legal age" check reads the clock, giving an answer of "yes". You then have a record of an apparent bug: it looks like "is legal age" returned "yes" one day too soon. | |
| Apr 5, 2022 at 18:33 | comment | added | JacquesB | @BlueRaja-DannyPflughoeft test doubles are a workaround for a problem that should not be there in the first place. Passing the date is both simpler and conceptually more correct. | |
| Apr 5, 2022 at 17:37 | comment | added | BlueRaja - Danny Pflughoeft | Yes, injected test doubles are the correct answer. Mangling your API to support testing should be a last resort. As a bonus, some languages (eg. Ruby, Python, JS) even let you mock static instances without dependency injection. | |
| Apr 5, 2022 at 15:28 | comment | added | chrylis -cautiouslyoptimistic- | Some systems (such as Java 8 time) have a concept of a Clock that can be replaced with a test double. | |
| Apr 5, 2022 at 6:31 | history | edited | JacquesB | CC BY-SA 4.0 | edited body |
| Apr 5, 2022 at 6:25 | history | answered | JacquesB | CC BY-SA 4.0 |