You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for the example code. Obviously, you've made some assumptions about how this particular code base works, but often the devil is in the details, so when I finally had a bit of time on my hands, I decided to try out the feature on the real code base. After a bit of back and forth, I wrote this test:
An important part of the Restaurant REST API design is that clients receive correct responses when things go wrong. That's the motivation for including a <code>ConcurrentBag</code> as part of the state, recording whether the response indicates success or failure.
292
+
</p>
293
+
<p>
294
+
To my disappointment, even when the race bug is absent (i.e. when transaction control is present in the service), this test fails. Here's a typical output from a failing test:
At first this is surprising, and upon further reflection, it may not be that surprising. Still, there are things that I don't understand.
312
+
</p>
313
+
<p>
314
+
Here's what's initially surprising: Implicit in this test is that the restaurant seats a maximum of 10 people a day. Thus, with 4, 1, and 4 seats being requested, it surprised me that <em>any</em> of these reservations were being declined. Still, all the linearized models have <code>{False, False, False}</code>; in other words, <em>no</em> reservations were accepted.
315
+
</p>
316
+
<p>
317
+
Then I remembered that this test is actually running on a real SQL Server database, and since I'm assuming that CsCheck has been running quite a few scenarios already, it actually makes sense that that particular day is already completely sold out. Does <em>72 skipped</em> indicate that there were 72 prior runs before this one? Or does it mean that CsCheck found a counterexample after 28 tries, and then decided to skip the remaining 72 runs?
318
+
</p>
319
+
<p>
320
+
In any case, even if it only did 27 prior runs, it seems likely that the date is already completely sold out. It then puzzles me that the final state is <code>{False, True, True}</code>. I honestly can't think of a good explanation of that, but perhaps you can?
321
+
</p>
322
+
<p>
323
+
In any case, I still think that I understand why this can't work as written above. The problem with filling up all reservations for a given date is the reason why I originally performed every attempt to provoke the race on a unique date. Is there a way to do that with CsCheck and <code>SampleParallel</code>?
324
+
</p>
325
+
<p>
326
+
Alternatively, one would need a way to tear down the persistent fixture (i.e. the database) after each run. I can't identify an API that enables me to do that, but perhaps I'm missing something. Is that option somehow available?
0 commit comments