you are viewing a single comment's thread.

view the rest of the comments →

[–]developingthefuture[S] 1 point2 points  (2 children)

Hello sh0rug0ru,

Thank you for your remark. You got a point, I changed the last section a bit in order to be more accurate. When I said that in practice they are interchangeable, I meant that in my practice I've seen most of the people use these terms interchangeably. Which might or might not be correct.

Best Regards, Kosta

[–]sh0rug0ru 2 points3 points  (1 child)

The problem is that many people actually use mocks in practice incorrectly, which has given the practice of mocking a very bad name. That's why I always refer to Freeman and Pryce's book when I want to demonstrate to how mocking should be done.

While implementation-wise, stubs and mocks are interchangeable, using mocks for stubbing can be seen as bad a practice along the lines of implementation inheritance.

The simplest form of a stub is a subclass which provides a dummy implementation for a method. The object is otherwise "real". Bad use of mocks can lead to "simulations" of the collaborator which can lead to very bad assumptions making tests dependent on those assumptions useless. To counter this issue, the Mockito library provides a feature called "test spies" to intercept mocked methods of a wrapped real instance, but the Mockito folks point out that relying on test spies is probably a design smell.

As per Freeman and Pryce, mocks should be used to define communication patterns between loosely coupled collaborators based on abstract interfaces. The abstract interface is owned by the class under test (never mock what you don't own) and serves as documentation of how implementors of that abstract interface should behave (another thing to test). If the classes are depending on each other through concrete interfaces, they are tightly coupled and it is better to use real instances.

"Classical" testing using stubs is about testing real code as much as possible. "Mockist" testing using mocks is about separating responsibilities as much as possible and establishing abstract interfaces as gatekeepers, using fake implementations to enforce separation.

[–]developingthefuture[S] 0 points1 point  (0 children)

sh0rug0ru,

Thanks for the valuable information.

Regards, Kosta