<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: 'a2'.<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: 'a2', 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: 'About to <span>serialize</span> an empty package.'].<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's rather a fixed ressource (see MCSnaphsotResource>>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's too obvious, isn't it?<br><br></div>But that's not enough... What is exactly the state retained in MCSnaphsotResource?<br>
Apparently #a already returns 'a2' 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'd say it'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'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>