Mock Objects

Another round in the testability debate

2008-03-08T09:52:00.003Z

This time a posting from Mark Seemann has raised a slew of comments.

One of them is a note from Colin Jack about the annoyance of producing interface/implementation pairs all the time. My first response is that that sounds to me a bit like a problem with style. Maybe it's just wordplay, but usually I don't extract interfaces from classes, I implement interfaces that I've already discovered in some previous test.

My second response is to wonder how much this is a tools issue. I don't believe there's anything in the .Net world that yet matches the responsiveness of the usual Java IDE's. It makes a difference as to what's plausible. I remember the huge shift in perception when first VisualAge for Java and then JetBrains' Idea came out. In retrospect, I always spent more on time on rework than many people I worked with ¹ but it sure took a lot more time in emacs (and I was pretty good at it), even if I was working in a better language.

1) which is not to say who was right, I'm just wired that way...

New Tutorial at QCon

2008-02-12T10:03:00.000Z

On Tuesday 11th March, at QCon London, Romilly Cocking and I will be running a new tutorial we're developing with Nat Pryce on Test-Driven Development with Mock Objects following on from a successful first run at the last XpDay. Sign up soon!

Just when you thought it was safe to go back in the water...

2008-01-20T11:57:00.000Z

Rising to the bait again (to keep the fishy metaphor going), there's yet another discussion of how the ability to hack the runtime changes the world. At one level that's true, but not in this case.

Dependency Injection is not a recent invention that a cabal of TDDers forced on the world, and it's absolutely not something that we came up with just so we could crowbar in our Mock Objects.

The relevant design guideline, named the Law of Demeter ("Strong Suggestion" isn't very catchy) was first described by Karl Lieberherr in 1987! The Mock Object pattern came from people applying their substantial O-O experience to TDD in Java, trying to figure out how best to avoid exposing implementation details in unit tests. One of the critical lessons from Demeter is that objects should have explicit dependencies. It helps to keep them focussed on their responsibilities and, as a result, easier to maintain—and a good way to make dependencies explicit is to pass them in.

Unfortunately, since then the world seems to have filled up with DI frameworks which cloud what should be a coding style discussion. This is not about having to configure every last corner of your application in XML, this is about how objects, or small clusters of them, get to talk to each other.

Roy asks, "[...] do you need DI all over the place, or just in specific places where you know dependencies could be a problem?" Well no—if you have enough foresight to know where those places are. I'm struggling at the moment to test against a framework where everything is helpfully packaged up nice and tight so I can't create an instance of one of its core objects. It's actually well written, but the authors just weren't good enough at prophecy to figure out my particular need. That's why I don't rely just on my intuition, I use the needs of my unit tests to help me figure out where the seams should be. To counter the FUD argument, I have absolutely no problem with saying that I don't want tools that do magic because I need guidance with my code.

As Roy (very politely) concludes, there isn't a high enough proportion of really good code in the world (some of it mine) that we should be in hurry to cut back on techniques such as DI. Just because something has been around for a while doesn't mean it's been superseded, especially in as conventional an environment as .Net.

Avoid mega unit tests

2008-01-13T09:59:00.001Z

We've just had a posting to the jMock user list that included the following:

I was involved in a project recently where JMock was used quite heavily. Looking back, here's what I found:

The unit tests where at times unreadable (no idea what they were doing).

Some tests classes would reach 500 lines in addition to inheriting an abstract class which also would have up to 500 lines.

Refactoring would lead to massive changes in test code.

I've seen this failure mode on another project I've been helping with, so I think there might be a common pattern.

I don't think any unit test code should get that large, except for unusual circumstances. Unit tests are supposed to focus on at most a few classes and shouldn't need a large amount of set up. What I saw on the other project was enormous amounts of preparation and positioning to get the objects into a state where the expected feature could be exercised. Of course it's hard to understand the point of a test when there's just so much code. If you see this pattern, then I'd suggest that the code (or at least the test code) needs breaking up a bit. On the other hand, integration and acceptance tests that happen to be written using a unit test framework might well be larger.

One thing I need to explore is whether the naive use of interaction-testing is particularly susceptible to this failing, or whether it happens all the time and we're the only ones who get complained to. I am, however, convinced that the emphasis on mainly using Mocks to substitute external systems (some of which I perpetrated myself in the early days) is a deeply bad idea which pushes teams towards the sort of problem described here.

Mock objects for Java ME

2007-12-22T14:13:00.000Z

Carl Meijer has asked us to announce his new project...

Yesterday I uploaded a personal project, Hammock, to sourceforge (http://sourceforge.net/projects/hammockmocks). This a mock object framework for Java ME. Java ME, unfortunately, doesn't support reflection making jMock, EasyMock, etc. unsuitable for use on a mobile device or emulator. Obviously this makes creating mocks more difficult than with the Java SE mock object frameworks but the distribution includes a utility, HammockMaker, for creating the source for a mock object given a class file (of a non-final class or of an interface). The framework includes mocks of many of the standard Java ME classes for communications such as HTTP, SMS, OBEX, etc so that one can test without actually hitting a network. I've used it on three projects at my current employer.

Don't tie down your code, use interfaces

2007-12-04T11:33:00.000Z

Recently, I was responding to a question on the TDD list and found myself writing this:

Although there's only one use of the interface, you could think of it as a way of keeping a clean distinction between the naming of different domains (user and persistence). It makes managing package dependencies easier too.

which is what I've been meaning to say for ages. The reason we're keen on discovering interfaces in our code is that we think they're a good way of expressing concepts in a domain.

If I'm writing a ring tones store (the video store folded last year) and I need to look up, say, the customers that were active last month, I'll ask a SalesLedger object. So, what type is SalesLedger? If it's a class then my marketing module will have a dependency on whatever persistence framework I use. If my SalesLedger class is clean and delegates to some further persistence type then I've only deferred the problem. I'm importing, directly or indirectly, the persistence packages into my domain code. If I do the same with a few other frameworks (printing, display, network, etc.) then I'll have tied down my domain module with third party dependencies. The module dependency chain looks like this:

There are two problems with this, one obvious and one subtle. The obvious point is that I've raised the risk of inflexible code. One day I'll have to rip out a messy chain of dependencies to get to some code I want to change. Now, because I'm another World's Greatest Software Developer, I'll be careful not to embed the dependency too deeply and keep my packages clean and layered, but that's intellectual overhead I could do without. When SalesLedger is an interface, I have a clear distinctions between the domains of marketing and persistence, and I cannot let the abstractions leak through. If I do this for all my external dependencies, I can package up my domain code and use it in all sorts of ways I haven't thought of yet. The top-level Application then becomes a matchmaker, introducing all the modules to each other and helping them get started.

The more subtle issue is that SalesLedger, the interface I use in the body of my code, is in a different domain from the HibernateLedger, a class that implements it (and maybe some other interfaces). The code that uses a SalesLedger is concerned with marketing and payments, the code that uses a HibernateLedger is concerned with setting up connections. There may only be one implementation of an interface, but the two types are addressing different things.

Is this breaking YAGNI? I don't think so (although there are others that do). I'm not adding features I haven't identified a need for yet. Part of the deal with YAGNI is that I make the code as expressive of my current intentions as I can, and I think I'm expressing the needs of the domain code needs more clearly by limiting its dependency to an interface that defines just the services it needs from other parts of the system.

n.b. Gulliver image taken from news.bbc.co.uk

MockObjects in Bangalore

2007-11-21T14:46:00.001Z

I'll be presenting a tutorial/workshop/Dojo on TDD with Mock Objects at Agile India in Bangalore this Sunday. I hope the locals will find the material interesting (and that they give me an easy ride while I struggle with the jet lag :).

"Testing towards A Specification: A Systematic Approach"

2007-10-19T10:19:00.000+01:00

Peter Dimov has published his Master's thesis. To quote him:

It is based on Test Driven Development with Mock Objects, hence the focus is on interaction-based testing. I'm introducing the mocking framework CalitkoMocks, which is specially designed to provide a notation for writing tests that can be mapped one-to-one to sequence diagrams. Sequence diagrams are classically used to specify object-oriented software systems, however, it is obvious that just a bunch of diagrams representing individual cases cannot really be regarded as a specification. To address this point, I'm also presenting a few test refactorings which help to extract test scenarios (i.e. generalized test cases), which are more suitable to use as a specification.

He's implemented a mock framework for C++ that's part of Calitko

I especially liked his closing remark

After I drew the diagram corresponding to my test, I decided to try to write a test corresponding one-to-one to the sequence diagram. The sequence diagram showed the calls to my stub objects but my test didn’t (because the implementation invoked them implicitly). I ended up writing smarter versions of my stubs which eventually evolved into mocks. Though I had already read about mocks at that time, I didn’t quite get it what kind of beasts these were. It was only after I reinvented the mock that I truly understood the concept.

Perhaps this is a step on the way to addressing Jason Gorman's concerns.

XpDay London 19/20 November

2007-10-16T13:29:00.000+01:00

We have a couple of sessions at XpDay London. Steve will be giving our Synaesthesia talk on Monday. On Tuesday, Nat, with Romily Cocking, Andy Pols, and Steve (part-time) will be giving an introductory tutorial on TDD with Mocks. Book soon!

Mock Throwable

2007-10-13T11:13:00.000+01:00

Yesterday I visited a team at a Cyrus Innovation site. They came up with this example. If you can't read it, the writing on the ball says "Throwable". Cute.

Blogger in German?

2007-10-02T00:14:00.000+01:00

On a side note, this blog is "powered by Blogger" and I keep getting bits of the UI text in German. Does anyone have any idea what's happening?

How to talk Mock

2007-10-01T23:48:00.000+01:00

Brian Marick has posted an interesting proposal for changing the order of the pieces within a unit test. For example, he suggests moving from

def test_checker_normally_checks_network_once 
  checker = testable_checker # creates checker using mocks.
  @network.should_receive(:ok?).once.with(”url”).and_return(true) 
  checker.check(”url”) 
end

def test_checker_normally_checks_network_once 
  checker = testable_checker 
  during { 
    checker.check(”url”) 
  }.behold! { 
    @network.should_receive(:ok?).once. 
             with(”url”).and_return(true) 
  } 
end

which shows what you can do if you have a language with useful constructs.

Personally, I've tended to think of stubs and expectations in terms of pre-conditions and post-conditions, so I find the pre-test setup less disturbing—and I've been doing it so long I don't see it any more. I imagine it's rather like getting used to (+ 1 2), which Brian ought to recognise. If I were to have a go, I think I might try to write some like this:

during {
  checker.check("url")
}.expect_to_see {
  @network.ok?("url") { returning true }
  @timesink.sleep_for(32.minutes) { 6.times }
  but_not @listener.inform
}

It's nice to see someone experimenting with the ideas.

GTAC. Google Test Automation Conference

2007-08-23T20:13:00.000+01:00

I'm at Google's Test Automation Conference in New York City (my old stamping ground from the '80's) and so far Mocks have been doing quite well. We had several mentions on his slides from Patric Copeland (Director of QA at Google).

There was also a presentation from Matt Heuser and Sean McMillan, "Examining Interaction-Based testing". I admit I feared a hatchet job but, actually, they presented a very balanced view. They had some good examples of Interaction Testing gone wrong, such as mocking out production code and not writing integration tests. They also pointed out the benefits of using TDD with mocks, including ending up with good code quality statistics implying good maintainability.

The one comment I had on the talk was to de-emphasise use of mocks to speed up unit test runs by mocking external (slow) resources. Our preference is to use mocks within our domain code but to try to write focussed integration tests at the outer boundaries of the system.

We don't need no stinking interfaces

2007-08-20T19:34:00.000+01:00

There's been another round of anti-Dependency Injection chatter in the blogsphere, so here we go again. Ayende's done a pretty good job of defending his response to the original posting. The arguments are the same as usual: we don't see why we should change our design just to make it testable. I would like to add a few comments to this round.

Static factories and the like are still dependencies, just implicit. Instead of making the dependencies clear in the code, so you can set up an object once and then just use it, statics force you to package up a load of hidden references with your class that aren't relevant after instantiation
I don't go around exposing private features all over the place. I expose the parts that need exposing because they express a relationship with a collaborator
As an author on the original papers, I resent quotes like
I wonder if this is a defensive reaction because the authors of the examples don’t want to have to justify making you fundamentally alter your coding habits and re-write all of your existing code just so that you can use their pet objects.
I'm used to being disagreed with over this technique, but this is a new one on me. Our approach to design has a long and very respectable history. If you're not aware of its roots, then maybe you should alter your coding habits.
I could do without some of the language, such as
"The emperor is naked" and you see it.
and
Take a look at what people are asking for on the xxMocks forums and the yahoo test-driven group and you will see how every problem that the tool can't solve is actually a design smell. Pragmatic development teams don't believe this anymore.
like we don't care about shipping reliable and effective systems.

One good thing this episode shows is that there are plenty of people who understand the issues and are prepared to engage.

AtomicObject use mocks for Embedded C

2007-08-20T17:26:00.000+01:00

At Agile 2007 I chaired an experience report session which had an elegant paper from AtomicObject on their approach to developing code for embdedded systems in C. The relevant bit for this blog is their use of interaction testing.

To make up for the lack of reflection in C, they defined conventions for their header files and wrote Ruby scripts in Rake to generate mocks and link in the right code for the unit tests.

Why did they go to all this trouble? In their words

our mocks revealed that some of the code was making calls it shouldn't have been

The mocks also helped us enforce single responsibility. Whenever the tests for a piece of code got too complicated, we could usually find a good way to break some of the complexity out into another module.

and from the presentation:

Interaction-based testing made tests easier to write and less brittle

It's nice to see the ideas port to a significantly different environment

Start with a working system

2007-07-04T16:56:00.000+01:00

Image we've just been commissioned to build a system, we have 30-inch monitors, we have the Customer in the room, we've prioritised some stories, now let's write a unit test! Well, maybe not yet. Our first test should be an attempt at something end-to-end that exercises a visibly useful feature (even if it's really, really tiny). To make this test pass, we'll need a Walking Skeleton, an absolutely minimal sliver of the whole system that actually works. To make the Walking Skeleton work, we'll have to think about the structure of the system, including build and deployment, which will help us flush out a whole Sackful¹ of project risk: our chosen messaging system doesn't work on our chosen platform, we need 4 weeks notice and 8 signatures to make a change to production, the target PCs only have 640K of RAM, and so on.

As a rule, we only discover this sort of issue when we actually try it, which is why we like to start with a build and deploy script, and then figure out what to put in it. We also prefer deploying as close to production as possible, since each step in the end-to-end journey brings its own challenges. This approach means we find the blockages at the start of the project, when we still have time to fix them, rather than at the end. In practice, of course, sometimes these steps take so long to implement that we start with a shadow system to stand in for our current interpretation of the real thing. But this is only a stop-gap, a temporary patch to allow us to make progress, it's not an acceptable end solution.

We need to make the point more strongly that unit-level testing (even using mocks!) should take place within the context of higher-level tests that set the direction for the current slice of development. The higher-level tests keep us focussed on what we need to implement next and keep us honest about what is working.

1) that's a level-2 Sackful, as defined in the PMBOK.

What does "easy" really mean?

2007-07-04T11:46:00.000+01:00

Steve's recent post about the perceived conflict between Testability and Design included this quote from a user of TypeMock:

The key benefit we get from TypeMock is having the ability to fully unit-test the code without impacting the API design. [...] For us, the API is part of the deliverable. We need to make it fairly easy to consume and can't have the architecture of the solution overshadow the usability of the API.

The crux of the issue is in the words "easy to consume". What does that mean? Easy to learn? Or easy to adapt to new, unanticipated situations.

For example, many developers find the java.io API complicated. This is how to open a file for reading:

Reader reader = new BufferedReader(new InputStreamReader(new FileInputStream("input.txt")));

The equivalents C or Python are much shorter, in Python:

reader = open("input.txt")

The Java version does, however, have a point. Is use of the Decorator and Chain of Responsibility patterns makes it easy to apply in different situations and adapt different underlying transports to the java.io stream model. In the C approach. different implementations are buried in the runtime, so you have to go to a different mechanism to try anything new.

TDD with mock objects drives an object-oriented design towards one like the java.io API. The design process focuses on discovering common patterns of communication between objects. The end-to-end system behaviour is defined by composing objects instead of writing algorithmic code. That makes code more malleable by experienced programmers but, arguably, makes it harder to learn for newcomers to the codebase or to object-oriented programming itself.

The problem can be addressed by layering expressive APIs that support common operations above the flexible, object-oriented core. A simple API is easy to learn but allows the programmer to drill down to the flexible core when new unexpected situations arise.

JMock itself follows this model. The core is an object-oriented framework for representing and checking expectations. This framework is flexible and extensible. You can create and compose objects to represent and test all sorts of expectations. This level of code, however, is too fine-grained to express the intent of a test. It's like trying to figure out what's for dinner from reading the recipes. That's why we also wrote a high-level API that is closer to the programmer's problem domain. It makes it easy for us to write readable code to set up framework objects and we still have the extension points we need when we need a new feature — and we can test jMock without manipulating bytecodes.

Making a point in IEEE Software

2007-06-15T13:52:00.000+01:00

We've had a position published (with Joshua Kerievsky on the other side) in the May/June issue of IEEE Software. To quote the abstract:

Point Argument: Mock Objects: Find Out Who Your Friends Are, by Steve Freeman and Nat Pryce. Mock objects help guide object-oriented programming by concentrating on what objects do, no what they are. Counterpoint Argument: TDD: Don't Much It Up with Too Many Mocks, by Joshua Kerievsky. Routinely test-driving code with mock objects leads to premature object composition, hard-to-read and fragile code, and lost time. This department is part of a special issue on test-driven development.

It looks like you have to pay (or get a copy of the magazine) to get the content. I'll ask if we can post our chunk. (thanks to the people who pointed out that you can download a different issue of the journal).

Test Smell: Too many expectations

2007-05-23T12:23:00.000+01:00

When a test has too many expectations it's hard to see what's important, what's really under test. For example, here's a test:

@Test public void decidesCasesWhenFirstPartyIsReady() {
  context.checking(new Expectations(){{
    one(firstPart).isReady(); will(returnValue(true));
    one(organiser).getAdjudicator(); will(returnValue(adjudicator));
    one(adjudicator).findCase(firstParty, issue); will(returnValue(case));
    one(thirdParty).proceedWith(case);
  }});
  
  claimsProcessor.adjudicateIfReady(thirdParty, issue);
}

that might be implemented like this:

public void adjudicateIfReady(ThirdParty thirdParty, Issue issue) {
  if (firstParty.isReady()) {
    Adjudicator adjudicator = organisation.getAdjudicator();
    Case case = adjudicator.findCase(firstParty, issue);
    thirdParty.proceedWith(case);
  } else{
    thirdParty.adjourn();
  }
}

What makes the test hard to read is that everything is an expectation, so everything seems to be equally important. I can't tell what's significant and what's just there to get me through the test.

In fact, if I look at all the methods I call, there are only two that have any side effects outside this class: thirdParty.proceedWith() and thirdParty.adjourn(). It would be an error to call these more than once. All the other methods are queries, I can call organisation.getAdjudicator() repeatedly without breaking any behaviour. adjudicator.findCase() might go either way, but it happens to be a lookup so it has no side effects.

I can make my intentions clearer by distinguishing between Stubs, simulations of real behaviour that help me get my test to pass, and Expectations, assertions I want to make about how my object interacts with its neighbours. Reworking my test, I get:

@Test public void decidesCasesWhenFirstPartyIsReady() {
  context.checking(new Expectations(){{
    allowing(firstPart).isReady(); will(returnValue(true));
    allowing(organiser).getAdjudicator(); will(returnValue(adjudicator));
    allowing(adjudicator).findCase(firstParty, issue); will(returnValue(case));
    
    one(thirdParty).proceedWith(case);
  }});
  
  claimsProcessor.adjudicateIfReady(thirdParty, issue);
}

which is explicit about how I expect my object to change the world.

Stub queries, mock actions

For the more formally minded, you might want to think (very, very loosely) of Stubs as pre-conditions and Expectations as post-conditions. The test now says that given the state described in the Stubs, the events described by the Expectations should have happened. Once I've sorted out which calls are Stubs, I can usually move some of them into common setup code, making the tests clearer still:

@Test public void decidesCasesWhenFirstPartyIsReady() {
  context.checking(new Expectations(){{
    allowing(firstParty).isReady(); will(returnValue(true));
    
    one(thirdParty).proceedWith(case);
  }});
  
  claimsProcessor.adjudicateIfReady(thirdParty, issue);
}

It is, of course, possible that all the methods calls are actions. In which case, either I just have a complicated domain and there's not much I can do to simplify it or, more likely, there are some intermediate concepts in there that need to be extracted into objects.

Clearly, when I'm thinking about the whole system, I can't ignore implementation issues such as the cost of database queries, but that's not relevant at this point. What matters now is that I have tests and code that clearly express my intentions.

On a side note, this is why I'm not keen on an expectation syntax like this: expect(firstParty.isReady()).stubReturn(true). I find the leading "expect" confusing, when my intention is to stub.

Special bonus prize

I always have problems coming up with good examples. There's actually a better improvement to this code, which is to notice that that I've pulled out a chain of objects to get to the case object, exposing dependencies that aren't relevant here. What I should have done is told the nearest object to do the work for me, like this:

public void adjudicateIfReady(ThirdParty thirdParty, Issue issue) {
  if (firstParty.isReady()) {
    organisation.adjudicateBetween(firstParty, thirdParty, issue);
  } else{
    thirdParty.adjourn();
  }
}

or, possibly,

public void adjudicateIfReady(ThirdParty thirdParty, Issue issue) {
  if (firstParty.isReady()) {
    thirdParty.startAdjudication(organisation, firstParty, issue);
  } else{
    thirdParty.adjourn();
  }
}

which looks more balanced. If you spotted this then I award you a Moment of Smugness™ to be exercised at your convenience.

Apache Camel

2007-05-21T20:03:00.000+01:00

The Apache ActiveMQ project has recently released Camel, a rule based routing and mediation engine for building enterprise integration systems. Camel provides a DSL-style Java API, inspired by jMock and LiFT, to specify rules for routing, transforming and monitoring messages and you can use mock message receivers to describe and verify expected message flows in tests.

Testability vs. Design (again)

2007-05-20T21:59:00.000+01:00

I'm sure TypeMock is a fine piece of software, but I just cannot agree with their notion that API design and testability are in conflict. Their new case study includes the statement:

The key benefit we get from TypeMock is having the ability to fully unit-test the code without impacting the API design. [...] For us, the API is part of the deliverable. We need to make it fairly easy to consume and can't have the architecture of the solution overshadow the usability of the API.

In the other corner we have Michael Feathers who has been running a tutorial called API Design as if Unit Testing mattered. Michael is one of the most interesting people I know on the Agile circuit, although he doesn't make a fuss about it. To quote him:

Have you ever tried to write a unit test for a class that uses an external API? An API that is not mockable? Testing seems to be the last thing on our minds when we design APIs. It isn't that we don't test our APIs, we just don't make it easy to test code that uses our APIs.

His point is that, for library designers, even writing tests for your API is not enough to produce something that's really useable, you have to try writing tests for the code that will use your API. Or, as Michael Puleio wrote,

If your API is hard to unit test, how in the heck are your users going to be able to use it?

What the tests will tell you

2007-05-14T14:35:00.000+01:00

We've found these benefits from learning to Listen to the Test Smells.

Keeping knowledge local: Some of the test smells we've identified, such as needing magic to create mocks, are to do with knowledge leaking between components. If I can keep knowledge local to an object, either internal or passed in, then its implementation is independent of its context. I can safely move it wherever I like. Do this consistently and I can build an application as a web of communicating objects.
If it's explicit I can name it: This is why I don't like mocking concrete classes, I like to have names for the relationships between objects as well the objects themselves. As the legends say, if I have something's true name then I can control it. If I can see it, I have more chance of finding other uses and so reducing duplication.
More names mean more domain information: I find that when we emphasise how objects communicate, rather than what they are, I end up with types and roles defined more in terms of the domain than of the implementation. I think this might be because I have more, smaller abstractions which gets me a further away from the underlying language. Somehow I seem to get more domain vocabulary into the code.
Pass behaviour rather than data: I find that TDD with mocks encourages me to write objects that tell each other what to do, rather then requesting and manipulating values. Applied consistently, I end up with a coding style where I pass behaviour (in listeners and callbacks) from the higher levels of the code to the data, rather than pulling data up through the stack. It's an unusual style in the Java/C# world, but I find that we get better encapsulation and clearer abstractions because I have to clarify what the pieces will do, not just what values they hold.

Object Collaboration Stereotypes

2007-05-09T13:00:00.000+01:00

Another diagnosis for a Bloated Constructor might be that not all of the arguments are dependencies, services that must be passed to the object before it can do its job. Other arguments might be more to do with structuring the implementation of the object or varying its behaviour to suit its neighbours. To help me think about this distinction, I've found it useful to categorise the peers of an object into four stereotypes:

Dependencies are services that the object needs from its environment so that it can fulfil its responsibilities.
Notifications are other parts of the system that need to know when the object changes state or performs an action.
Policies are objects that tweak or adapt the object's behaviour to the needs of the system.
Parts are components in the implementation that are not controlled from outside the object after being set.

Dependencies must be passed in through the constructor. An object needs the system to provide implementations of its dependencies to function at all, so there's no point in creating an instance until they're available. Partially creating an object and then finishing it off by setting properties is risky and brittle because the programmer has to know whether all the dependencies have been set. As Yoda said, "New, or new not. There is no try."

Other types of peer can be passed to the constructor as a convenience but, if the list is becoming too long, they can also be initialised to safe defaults and overridden later (one way to distinguish the two is that there are no safe defaults for a Dependency). Policies and Parts can be initialised to commonly used cases, and collections of Parts can be initialised as empty. I can then add setters and add/remove methods to the class to allow the object's clients to configure it. Similarly, Notifications can be implemented as events. Unicast events can be initialised with a null implementation of the listener interface, and multicast events can be initialised with an empty collection of listeners. I always create a valid object, and I also have the hooks I need for testing.

A high speed example

Here's an example, it's probably not quite bad enough to need fixing, but it'll do to make the point. The application is a Formula 1 racing game, players can try out different configurations of car and driving style to see which one wins. A RacingCar represents a competitor within a race.

public class RacingCar {
  private final Track track;
  private Tyres tyres;
  private Suspension suspension;
  private Wing frontWing;
  private Wing backWing;
  private double fuelLoad;
  private CarListener listener;
  private DrivingStrategy driver;

  public RacingCar(Track track, DrivingStrategy driver, 
                  Tyres tyres, Suspension suspension, 
                  Wing frontWing, Wing backWing, double fuelLoad,
                  CarListener listener)
  {
    this.track = track;
    this.driver = driver;
    this.tyres = tyres;
    this.suspension = suspension;
    this.frontWing = frontWing;
    this.backWing = backWing;
    this.fuelLoad = fuelLoad;
    this.listener = listener;
  }
}

It turns out that the track is the only Dependency of a RacingCar, the hint is that it's the only field that's final. The driver is a Policy, the listener is a Notification, and the rest are Parts; all of these can be modified by the user before or during the race. Here's a reworked constructor:

public class RacingCar {
  private final Track track;

  private DrivingStrategy driver = DriverTypes.borderlineAggressiveDriving();
  private Tyres tyres = TyreTypes.mediumSlicks();
  private Suspension suspension = SuspensionTypes.mediumStiffness();;
  private Wing frontWing = WingTypes.mediumDownforce();
  private Wing backWing = WingTypes.mediumDownforce();
  private double fuelLoad = 0.5;

  private CarListener listener = CarListener.NONE;

  public RacingCar(Track track) {
    this.track = track;
  }
    
  public void setSuspension(Suspension suspension) { …
  public void setTyres(Tyres tyres) {  …
  public void setEngine(Engine engine) {  …
   
  public void setListener(CarListener listener) {  …
  …
}

Now I've initialised the peers to most common defaults, the user can then configure them through the user interface. I've initialised the listener to a null implementation, again this can be changed later by the object's environment.

A matter of taste

These stereotypes are only heuristics to help me think about the design, not hard rules, so I don't get obsessed with finding just the right classification of an object's peers. What matters most is the context in which I'm developing the object, my mental model of the domain. For example, an auditing log might be a Dependency, since it's a legal requirement for the business, or a Notification, since the object will otherwise function without it. Policies belong to the environment and can usually be constants, since they're often immutable and so don't need to be instantiated more than once. Parts belong to the object and usually cannot be stateless, so they need a new instance. For example, in my Racing Car, tyres might be a Policy if TyreTypes.mediumSlicks() describes only how the choice of tyre affects the car's handling, but a Part if it stores mutable values such as air pressure and wear.

Mocking classes challenge

2007-05-08T14:10:00.000+01:00

I'm in a communcation quandry. I'm either missing a point or can't explain something, or both.

I really don't like mocking classes, except where I'm trying to cut a seam in some legacy code, but other people disagree.

Can someone post or send me an example of code where interaction-testing with interfaces doesn't work well? Thanks

Contact me at mockexample theAtSymbol m3p theDotCharacter co anotherDotHere uk

Cross-referencing Code Smells

2007-05-02T17:12:00.000+01:00

While we've been writing up our Test Smells, here's a good summary of some Code Smells