Comment on An abstract example of refactoring from interaction-based …

…to property-based testing

_posts/2023-04-03-an-abstract-example-of-refactoring-from-interaction-based-to-property-based-testing.html

@@ -424,4 +424,26 @@ <h3 id="b0e7738d8b0440bba33caa470fd440fb">
     <p>
         <strong>Next:</strong> A restaurant example of refactoring from example-based to property-based testing.
     </p>
+
+    <div class="comment" id="0510331b953a4c308c3b01a918d2b65c">
+        <div class="comment-author"><a href="https://github.com/srogovtsev">Sergei Rogovtcev</a></div>
+        <div class="comment-content">
+            <p>First of all, thanks again for continuing to explore this matter. This was very enlightening, but in the end, I was left with is a sense of subtle wrongness, which is very hard to pin down, and even harder to tell apart between "this is actually not right for me" and "this is something new I'm not accustomed to".</p>
+
+            <p>I suppose that my main question would center around difference between your tests for <code>IStateValidator</code> and <code>IRenderer</code>. Let's start with the latter:</p>
+
+            <blockquote><p>Instead of configuring an <code>IRenderer</code> Stub, the test can state the expected output: That the output is equal to the output that <code>renderer.Success</code> would return.</p></blockquote>
+
+            <p>Coupled with the explanation ("[the test] has less of an opinion about the implementation, which means that it's marginally less coupled to it"), this makes a lot of sense, with the only caveat that in more production-like cases comparing the output would be harder (e.g., if <code>IRenderer</code> operates on <code>HttpContext</code> to produce a full HTTP response), but that's a technicality that can be sorted out with proper assertion library. But let's now look at the <code>IStateValidator</code> part:</p>
+
+            <blockquote><p>as far as executable specifications go, this test doesn't reflect reality. There's only one <code>Validate</code> implementation, and it doesn't behave like that. Rather, it'll return true when code is equal to <code>knownState.expectedCode</code>. The test poorly communicates that behaviour. </p></blockquote>
+
+            <p>Here you act with the opposite intent: you want the test to communicate the specification, and thus be explicitly tied to the logic in the implementation (if not the actual code of it). There are two thing about that that bother me. First of all, it's somewhat inconsistent, so it makes it harder for me to choose which path to follow when testing the next code I'd write (or articulating to another developer how they should do it). But what's more important - and that comes from my example being <em>minimal</em>, as you've already noted - is that the validation logic might be more complicated, and thus the setup would be complicated as well. And as you've already mentioned on Twitter, when chaging the code in the validator implementation, you might be forced to change the implementation in the test, even if the test is more about the controller itself.</p>
+
+            <p>There's also another frame for the same issue: the original test read as (at least for me): "if the state is valid, we return successful response based on this state". It didn't matter what is "valid" not did it matter what is "successful response". The new tests reads as "if state in the repository matches passed code, we return successful response for the state". It still doesn't matter what is "successful response", but the definition of validity <em>does</em> matter. For me, this is a change of test meaning, and I'm not sure I understand where that leads me.</p>
+
+            <p>Let's consider the following scenario: we need to add another validity criteria, such as "state in repository has an expiration date, and this date should be in the future". We obviously need to add a couple of tests for this (negative and positive). Where do we add them? I'd say we add them into the tests for the validator itself (which are "not shown" for the purposes of brevity), but then it feels weird that we <em>also</em> need to change this "happy path" test...</p>
+        </div>
+        <div class="comment-date">2023-04-03 21:24 UTC</div>
+    </div>
 </div>