<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div>The test relies on<br><br>mockDiffyVersion<br>    | repos workingCopy base next |<br>    repos := MCDictionaryRepository new.<br>    workingCopy := MCWorkingCopy forPackage: self mockPackage.<br>
    workingCopy repositoryGroup addRepository: repos.<br>    MCRepositoryGroup default removeRepository: repos.<br>    base := self mockVersion.<br>    repos storeVersion: base.<br>    self change: #a toReturn: &#39;a2&#39;.<br>
    next := self mockVersionWithAncestor: base.<br>    ^ next asDiffAgainst: base    <br><br>As I said in another thread, this test is not working as intended.<br>Despite the intention to change #a toReturn: &#39;a2&#39;, and thus have a diff,<br>
</div>the base version and next version share the same snapshot.<br></div>Thus there is no change detected.<br>Thus there is a [Warning  signal: &#39;About to <span>serialize</span> an empty package.&#39;].<br></div><br></div>
</div></div>The first reason why this is not working is because #mockVersion and #mockVersionWithAncestor both send #mockSnapshot.<br>But #mockSnapshot is not dynamic, it&#39;s rather a fixed ressource (see MCSnaphsotResource&gt;&gt;snapshot, setUp, takeSnapshot).<br>
</div>So the first thing is to change mockVersionWithAncestor: to use (self mockPackage snapshot instead) of (self mockSnapshot) - oh yeah that&#39;s too obvious, isn&#39;t it?<br><br></div>But that&#39;s not enough... What is exactly the state retained in MCSnaphsotResource?<br>
Apparently #a already returns &#39;a2&#39; in the snapshot, probably because this is what is stored in the Tests package.<br></div><div>And this is what is stored in Tests package probably because MCSerializationTest never invoke #restoreMocks. Some SUnit do this in the tearDown, but it looks like random to me...<br>
</div><div><br>So we have many tests messing with a global state... This global state creates many interactions.<br>As someone who did not write these tests, I&#39;d say it&#39;s impossible to get a clear picture ot all those interactions, even after a few hours of browsing and debugging.<br>
</div><br></div><div>So who should send restoreMocks?<br></div>There is not a comment anywhere explaining what the responsibilities and the contracts are.<br></div><div>It&#39;s very good to have self explaining code, but here, having no guideline for such a complex beast, I personnally see it as self fooling code.<br>
</div></div>