tag:blogger.com,1999:blog-9238405.post8299961069947177402..comments2024-03-18T02:04:50.380-07:00Comments on Agile Testing: Mock testing examples and resourcesGrig Gheorghiuhttp://www.blogger.com/profile/17863511617654196370noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-9238405.post-36166470772574933562012-10-02T11:07:30.375-07:002012-10-02T11:07:30.375-07:00One of the things I find very frustrating about ha...One of the things I find very frustrating about having a lot of mocks in unit tests is how brittle these tests become when collaborators are changed. Unit tests should take more of a black box approach and having loads of mocks couples them heavily to the implementation of the software under test.Anonymoushttps://www.blogger.com/profile/02103935836118167629noreply@blogger.comtag:blogger.com,1999:blog-9238405.post-52621695397530520582008-07-28T12:59:00.000-07:002008-07-28T12:59:00.000-07:00I've read all of these arguments. Many good ideas ...I've read all of these arguments. Many good ideas were exchanged, but it seems as if everyone was missing the obvious. Finally I read the comment by jyaunches. Exactly what was on my mind.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9238405.post-78963931047879165232007-11-01T10:43:00.000-07:002007-11-01T10:43:00.000-07:00I found some useful examples at http://www.mocksam...I found some useful examples at http://www.mocksamples.org/Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9238405.post-84917151421194261862007-03-13T18:50:00.000-07:002007-03-13T18:50:00.000-07:00In reference to the argument about when to use moc...In reference to the argument about when to use mocks you said... 'There's a good chance the behavior/interface of those objects will change, and you'll have the situation where the unit tests which use mock versions of these objects will pass, when in fact the application as a whole will fail.' I don't believe this to be a valid argument. Mocked versions of any object used for testing a class are, assumingly, collaborating objects with actual class/object under test. These objects should have their own unit test. When this fails due to changing functionality, you can update it's tests accordingly. The only problem I see is in inaccurately mocked objects as collaborators in other test classes.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9238405.post-61760117554463828732007-01-26T17:45:00.000-08:002007-01-26T17:45:00.000-08:00"His main point is that if you mock an object and ..."His main point is that if you mock an object and the interface or behavior of that object changes, your unit tests which use the mock will pass happily, when in fact your application will fail."<br /><br />This is a very real problem. I've recently seen this in an application and it just blew my mind. Why do some people apply mocks and stubs to absolutely all aspects of testing? I've heard that some people like fixture-less testing which will increase the speed of their tests, but if speed is what they're worried about they don't seem to be worried about the right thing.<br /><br />"I agree with Bruce that you shouldn't go overboard with mocking objects that you create in your own application. There's a good chance the behavior/interface of those objects will change, and you'll have the situation where the unit tests which use mock versions of these objects will pass, when in fact the application as a whole will fail. This is also a good example of why unit tests are not sufficient;"<br /><br />Exactly!<br /><br />Thats for the article. This was a great read.Zach Dennishttps://www.blogger.com/profile/00224549516572642650noreply@blogger.com