comment: Test Double clocks

Author: c-vetter

_posts/2022-06-27-test-double-clocks.html

@@ -378,4 +378,63 @@ <h2 id="comments-header">
 		</div>
 		<div class="comment-date">2022-06-30 7:43 UTC</div>
 	</div>
+	<div class="comment" id="5aa51b5af530409290c0944b07ce9b10">
+		<div class="comment-author"><a href="https://github.com/c-vetter">C. Vetter</a> <a href="#5aa51b5af530409290c0944b07ce9b10">#</a></div>
+		<div class="comment-content">
+			<figure class="quote">
+				<blockquote>
+					Yeah, not really. This isn't worse, but neither is it better. It's the same size of code, and while the dates are now explicit (<a href="https://peps.python.org/pep-0020/">which, ostensibly, is better</a>), the reader now has to deduce the relationship between the clock offset, <code>r1</code>, and <code>r2</code>. I'm not convinced that this is an improvement.
+				</blockquote>
+			</figure>
+			<p>I think, you overlook an important fact here: It depends™.</p>
+
+			<p>
+				As <a href="https://youtu.be/pSOBeD1GC_Y">Obi Wan taught us</a>, the point of view is often quite important.
+				In this case, yes it's true, the changed code is more explicit, from a certain point of view, because <em>the dates are now explicit</em>.
+				But: in the previous version, the <em>relationships were explicit</em>, whereas they have been rendered implicit now.
+				Which is better depends on the context, and in this context, I think the change is for the worse.
+			</p>
+
+			<p>
+				In this context, I think we care neither about the specific dates nor the relationship between both reservation dates.
+				All we care about is their relationship to the present and that they are different from each other.
+				With that in mind, I'd suggest to extend your <code>Some</code> container with more datetimes, in addition to <code>Now</code>,
+				like <code>FutureDate</code> and <code>OtherFutureDate</code>.
+			</p>
+
+			<p>
+				How those are constructed is generally of no relevance to the current test.
+				After all, if we wanted to be 100% sure about every piece,
+				we'd basically have re-write our entire runtime for each test case, which would just be madness.
+				And yes, I'd just construct them based on the current system time.
+			</p>
+
+			<p>
+				Regarding the overall argument, I'll say that dealing with time issues is generally a pain,
+				but most of the time, we don't really need to deal with what happens at specific times.
+				In those rare cases, yes, it makes sense to fix the test's time, but I'd leave that as a rare exception.
+				Partly because such tests tend to require some kind of wide-ranging mock that messes with a lot of things.
+			</p>
+
+			<p>
+				If we're talking about stuff like Y2k-proofing (if you're too young to remember, look it up, kids),
+				it bears thinking about actually creating a whole test machine (virtual or physical)
+				with an appropriate system time and just running your test suite on there.
+				In times of docker, I'll bet that that will be less pain in many cases than adding time-fixing mock stuff.
+			</p>
+
+			<p>
+				If passage of time is important, that's another bag of pain right there,
+				but I'd look into segregating that as much as possible from everything else.
+				If, for example, you need things to happen after 100 minutes have passed,
+				I'd prefer having a single time-based event system that
+				all other code can subscribe to and be called back when the interesting time arrives.
+				That way, I can test the consumers without actually travelling through time,
+				while testing the timer service will be reduced to making sure that events are fired at the appropriate times.
+				<small>The latter could even happen on a persistent test machine that just keeps running,
+				giving you insight on long-time behavior (just an idea, not a prescription 😉).</small>
+			</p>
+		</div>
+		<div class="comment-date">2024-05-08 11:13 UTC</div>
+	</div>
 </div>