tag:blogger.com,1999:blog-364616448054212690.post4339102228586303926..comments2024-02-03T14:06:15.407+01:00Comments on Michał Komorowski: 3 reasons why I don't use strict mocksMichał Komorowskihttp://www.blogger.com/profile/05521807053068126888noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-364616448054212690.post-36568049383920560322016-11-18T09:11:46.775+01:002016-11-18T09:11:46.775+01:00"When adding new method to class breaks Your ..."When adding new method to class breaks Your tests, it's obviously a design issue."<br /><br />Adding a method to a class will not break unit tests based on strict mocks (at least it shouldn't). However, using this new method can break unit tests because strict mocks works in this way. Unit tests can also start failing if you change order of methods calls, change values of parameters... The problem is that unit tests will start failing not because something is wrong in your code, but because a configuration of a test is not proper.<br /><br />"That exception You provided - main problem is calling Dispose in destructor...."<br /><br />You are right that it's not guaranteed when a destructor will be called. However, it is how Dispose pattern should be implemented according to my knowledge. Of course, it's better to explicitly call Dispose method or use using clause and not to wait for GC.<br /><br />"Thrid reason You provided - when You cannot tell when method is used - something is wrong."<br /><br />You have to remember that unit tests is not the same thing as a fully fledged application. In the real application, for example a DI container may be responsible for disposing objects. Whereas in unit tests we rather creates objects on our own. In that case we may "forget" that a given class is disposable (as in the example).<br /><br />Besides, my 3rd reason doesn't state that it is difficult to say "when method is used". It says that it is difficult to say "which method are used". It may sound surprising but if you work with big projects, that are developed by many developers... you simply doesn't know all the details and you may overlook that some methods should be configured for a strict mock.Michał Komorowskihttps://www.blogger.com/profile/05521807053068126888noreply@blogger.comtag:blogger.com,1999:blog-364616448054212690.post-39574743680388042762016-11-18T00:25:49.842+01:002016-11-18T00:25:49.842+01:00I cannot agree with You. When adding new method to...I cannot agree with You. When adding new method to class breaks Your tests, it's obviously a design issue. Broken tests may tell You, that You are violating Open-Closed principle. So You want to rethink Your solution.<br />That exception You provided - main problem is calling Dispose in destructor. If i remember correctly, You cannot tell when destructor will be called, and You cannot be 100% sure that it will be finished(example - You want to free the handle, which was "destroyed" before(Weak reference, any other thingie that allows GC to remove object, even, when it can be reached). So, IMHO, calling "Dispose" method should be determined accurately by programmer. <br />Thrid reason You provided - when You cannot tell when method is used - something is wrong. If Your code is nondeterministic - how You can assure that it works? <br />Anonymoushttps://www.blogger.com/profile/00859463802549790613noreply@blogger.com