MockObjects

From CitconWiki
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

SF: this is the way we see mocks - it's one school of OO, not the only one.

most oo schools teach classification and that is the wrong stuff, it's about the roles

CRC Rebecca Wirfs-Brocks "Object design"

collaborating objects with well defined responsibilities. how do we test responsibilities of the object? state isn't part of that. fire an event and see that the appropriate messages have been sent to its collaborators. we mock when the external service changes the external world; we stub when it doesn't change the external world. stub queries and mock actions. use mocks as a design tool, not primarily to isolate dependencies. "to prove that this works we need a thingy but we don't have that thingy yet, so we define it with a mock". work your way through the slice of a system until you get to something external.

interface tells you what methods you can call, not when and how to call them. it doesn't specify the contract. this is where mocks come in.

don't enforce rigid rules (eg whenever you have an interface you need a mock)

massive mistake - try and mock java libraries. "mock external resources" - don't do that.

focus on precise service that your class needs - eg db access, repositories. db implementation gets integration tested.

lock all dependencies down, make it final; that forces you to clear up where the dependencies are

just before you hit external dependencies, define the interface in your domain;

alistair cockburn ports and adapters. the domain is in the middle. external stuff is in the middle and the adapters. test adapters with the real thing.

mocking concrete classes. it's something you care about to mock but you haven't made that relationship explicit in code. interface suggests role, class might have lots of other methods there. after refactoring things can become convoluted. if the interface isn't there than the relationship is just implicit. creating an interface also forces you to find a name for it so you might discover other things that weren't obvious. need to mock out concrete classes suggests that the class has too many roles so it might need refactoring.