Let me explain by starting from the beginning: a typical interaction based test with mocks (using some pseudo-mocking syntax):

#1

Here is what the test tells me:

- When you read the article
- then the reader.read() should be called
- and NO other method on the reader should be called.

Now, let's have a look at typical state based test with assertions:

#2

Which means:

- When you read the article
- then the article should be read.

Have you noticed the subtle difference between #1 and #2?

In state testing, an assertion is focused on a single property and doesn't validate the surrounding state. When the behavior under test changes some additional, unexpected property - it will not be detected by the test.

In interaction testing, a mock object validates all interactions. When the behavior under test calls some additional, unexpected method on a mock - it will be detected and UnexpectedInteractionError is thrown.

I wonder if interaction testing should be extra defensive and worry about the unexpected?

Many of you say 'yes' but then how come you don't do state based testing along this pattern? I'll show you how:

#3

Which means:

- When you read the article
- then the article should be read
- and no other state on the article should change.

Note that the assertion is made on the entire Article object. It effectively detects any unexpected state changes (e.g: if read() method changes some extra property on the article then the test fails). This way a typical state based test becomes extra defensive just like typical test with mocks.

The thing is state based tests are rarely written like that. So the obvious question is how come finding the unexpected is more important in interaction testing than in state testing?

Here is my theory: The simplest way to implement a state testing was to provide bunch of assertions (and a runner). Hence simple run->assert. The simplest way to implement interaction testing was to provide pre-programmable mocks that can be "expected", stubbed with necessary return values, and later strictly verified. Hence extra defensive expect->run->verify. I guess the implementation details influenced the interface and defined the patterns of state testing and interaction testing.

I guess it's easier to detect the unexpected with interaction testing (because most mocking frameworks just work like that by default) than with state testing (because I have to build up an expected object which is somewhat unnatural, see #3).

Now, let's consider pros & cons. Surely detecting the unexpected seems to add credibility and quality to the test. Sometimes however, it just gets in the way, especially when doing TDD. To explain it clearer let's get back to the example #3: the state based test with detecting the unexpected enabled. Say I'd like to test-drive a new feature:

#4

I run the tests to find out that newly added test method fails. It's time to implement the feature:

I run the test again and the new test passes now but hold on... the previous test method fails! Note that the existing functionality is clearly not broken.

What happened? The previous test detected the unexpected change on the article - setting the date. How can I fix it?

1. I can merge both test methods into one which is probably a good idea in this silly example. However, many times I really want to have small, separate test methods that are focused around behavior. One-assert-per-test people do it all the time.

2. Finally, I can stop worrying about the unexpected and focus on testing what is really important:

public shouldSetReadDateWhenReading() {
  article.read();
  assertEquals(today(), article.getReadDate());
}

public shouldReadArticle() {
  article.read();
  assertTrue(article.isRead());
}

Ok, I know the example is silly. But it is only to explain why worrying about unexpected may NOT be such a good friend of TDD or small&focused test methods.

Let's get back to mocking.

Most mocking frameworks detect the unexpected by default. When new features are test-driven as new test methods, sometimes existing tests start failing due to unexpected interaction errors. What happens next?

1. Junior developers copy-paste expectations from one test to another making the test methods overspecified and less maintainable.

2. Veteran developers modify existing tests and change the expectations to ignore some/all interactions. Most mocking frameworks enables developers to ignore expectations selectively or object-wise. Nevertheless, it is still a bit of a hassle - why should I change existing tests when the existing functionality is clearly not broken? (like in example #4 - functionality not broken but the test fails). The other thing is that explicitly ignoring interactions is also a bit like overspecification. After all, to ignore something I prefer just not to write ANYTHING. In state based tests if I don't care about something I don't write an assertion for that. It's simple and so natural.

To recap: worrying about the unexpected sometimes leaves me with overspecified tests or less comfortable TDD. Now, do I want to trade it for the quality? I'm talking about the quality introduced by extra defensive test?

The thing is I didn't find a proof that the quality improves when every test worries about the unexpected. That's why I prefer to write extra defensive tests only when it's relevant. That's why I really like state based testing. That's why I prefer spying to mocking. Finally, that's why I don't write verifyNoMoreInteractions() in every Mockito test.

What do you think? Have you ever encountered related problems when test-driving with mocks? Do you find the quality improved when interaction testing worries about the unexpected? Or perhaps should state testing start worrying about the unexpected?

Interessante anche l'excursus sulla storia dei mock objects, nati in Connextra

The story I heard was that it was all started by John Nolan, the CTO of a startup named Connextra. John Nolan, gave his developers a challenge: write OO code with no getters.  Whenever possible, tell another object to do something rather than ask.  In the process of doing this, they noticed that their code became supple and easy to change.

La frase chiave:

We need practices which help us achieve continuous discipline and a continuous state of reflection.  Clean Room and TDD are two practices which, despite their radical differences, force us to think with absolute precision about what we are doing.

My chief complaint, as the doctors say, was that Mocking introduced an unnecessary level of complexity to your testing code.  My secondary complaint was that it broke encapsulation by giving your test code too much insight as to the expected implementation of your classes, what with all the .expect()s and .will()s floating around.  It's like washing the family car with your Dad hovering over your shoulder, telling you the right way to use the sponge.  As long as it's clean at the end, who cares?

In a nutshell, this is the argument over state-based vs. behavioral testing.  In state-based testing, you just want Car.IsClean() to return true.  In behavioral testing, you want Sponge.Wipe() to be called 137 times, and Hose.Spray() to be called 22 times.

Call me a keen proponent of state-based testing.

There are a couple areas where Mocking can get around very real weaknesses in state-based testing; for example, anything to do with nondeterministic behavior.  The authors of this paper, "Mock Roles, Not Objects", conveniently use caching as a way to explore Mocking, and it make sense.  It would be hard to test caching to that level of detail without either (a) Mocks or (b) exposing a lot of guts of the implementation just to hang test hooks off of.

What's your experience with Mocking?  Any best practices to relate?

Reading Martin Fowler's article Mocks Aren't Stubs l came to realize that at the time of writing the article I was very much a mockist. I'm probably still a mockist, in my opinion mock objects is an excellent technical aid when doing TDD and I always felt that using mock objects improve my design. But having used mock objects for a while now, I can see some very clear disadvantages. Amongst other the amount of setup code needed may lead to a maintenance burden if you are not careful. If you start to experience refactoring as a painful exercise, than you probably have a problem. If refactoring is hard you will not favour change. And if you cannot change your code you end up with crap that is hard to maintain...  I've seen this happen and I'm trying my best to avoid this pain in the future. One way of avoiding this is to start treating your test classes as first class citizens and realize that whenever you write code you have increased the maintainance burden for the system.

More to come on this subject, hopefully....

[TestFixture]
public class SalesTests
{
private MockRepository mockery;

[SetUp]
public void BeforeTest()
{
mockery = new MockRepository();
}

[TearDown]
public void AfterTest()
{
mockery.VerifyAll();
}

[Test]
public void ShouldbeAbleToPrintReceiptForASaleWithNoItems()
{
var sale = new Sale();
var renderer = mockery.StrictMock<IRender>();
renderer.Render(”Total Taxes: 0.00 \n Total: 0.00″);
mockery.ReplayAll();
sale.PrintReceiptOn(renderer);

}
}
the implementation needed to pass the above test was as follows

public interface Renderer{
void render(String s);
}
public class Sale {

public void PrintReceiptOn(IRender renderer)
{
renderer.Render(”Total Taxes: 0.00 \n Total: 0.00″);
}

By driving the design test first I was able to discover the need for an object to play the Renderer role, using mocks I was able to drive out interface for the Renderer role.
But I also realised later the above test was brittle and over specified, because
the test was very tightly coupled to the implementation, because the conversation between the objects was not at the right level.
for instance if I changed the implementation of printReceiptOn on the Sale object to

public void PrintReceiptOn(IRender renderer)
{

renderer.Render(”Total Taxes: 0.00″);
renderer.Render(”Total: “);
renderer.Render(”0.00″);
}

The test will break (because the test specifies the Render message be sent to the renderer only once with a specific argument) although the implementation is
quite valid. So the test is tightly coupled to the implementation
Now we could try addressing the symptom by defining a looser constraint on the test as shown below

[Test]
public void ShouldbeAbleToPrintReceiptForASaleWithNoItems()
{
var sale = new Sale();
var renderer = mockery.StrictMock<IRender>();
renderer.Render(”Total: 0.00″);
LastCall.Repeat.AtLeastOnce().IgnoreArguments();
mockery.ReplayAll();
sale.PrintReceiptOn(renderer);

With the above either of my previous implementation would make the
test pass. however it doesn’t test the right data was being rendered.

To ensure that the right data was being rendered
We could write a state-based using a collecting stub to verify the data being
rendered is correct as shown below
[Test]

public void VerifyReceiptContentsForSaleWithNoItems() {
TestRenderer renderingDevice = new TestRenderer();
sale.printReceiptOn(renderingDevice);
Assert.assertEquals(”Total Taxes: 0.00 \n Total: 0.00″,
renderingDevice.GetContents());

}

where TestRenderer is a collecting stub which is implemented as follows

public class TestRenderer : IRenderer {
private String contents;

public void Render(String s) {
contents += s;
}
public String GetContents() {
return contents;
}
}
At this point I was questioning the usefulness of a mock, it seemed I was better off using a state based test and using a colleting stub to verify. The brittleness of our initial interaction based test, indicated an underlying design issue, interaction was not specified at the right level. The trick here is to design interactions that are meaningful to the calling object, this leads to interface discovery, (and this is one of the reasons why you should not mock 3rd party API's). Now Render(string s) is not a meaningful message to the Sale object to be sending to the Renderer, the Sale object knows about items, taxes and total so What would have been more a meaningful interaction (conversation ) between the Sale object and Renderer would be to specify the interaction in terms of taxes, items and total, as shown below.

[Test]
public void ShouldbeAbleToPrintReceiptOnAPrinterForSaleWithNoItems()
{
renderer.RenderTaxes(0.0m);
renderer.RenderTotal(0.0m);
mockery.ReplayAll();
saleUnderTest.PrintReceiptOn(printer);
}
public interface Renderer {
void RenderTotal(decimal total);
void RenderTaxes(decimal taxes);
}

the following is now the implementation of the PrintReceiptOn method of the Sale Object

public void PrintReceiptOn(IRender renderer)
{

renderer.RenderTaxes(totalTaxes);
renderer.RenderTotal(total);
}
This is where mock objects are so useful as they aid in the discovery of interfaces and quickly give us feedback in the form of brittle tests when interactions between objects are poorly designed.

In this IBM developerWorks tutorial, I will explain how you can use Apache Synapse to create mock Web services. The target Web service clients and services can be in any language, such as Microsoft® .NET, Java, or PHP. You will work with several samples, starting from the most basic configuration and gradually building more complex solutions to create mock Web services.

Read the article at http://www.ibm.com/developerworks/webservices/edu/ws-dw-ws-synapse.html

It's open for everyone so don't plan anything for the last Wednesday of May.

The topic concentrates around mocking. There will be jMock guys selling jMock and Felix talking about Mockito. Trust me, even if you know everything about mocking, this session will be interesting.

I'm not going to be there because in few days I'm moving to a different country :)

I'm about to show that it is very useful to distinguish two basic kinds of interactions: asking an object of data and telling an object to do something. Fair enough, it may sound obvious but most mocking frameworks treat all interactions equally and don't take advantage of the distinction.

Let's have a look at this piece of code:

Before mocking was invented we manually wrote stubs and tests looked like this:

Sometimes I miss those days before mocking. Test code looked so nice... The only problem was that hand writing every stub was quite cumbersome and produced tons of extra code.

Anyway, let's try to extract a pattern from above test code:

1. when the repository is asked to find "foo" article, then return article
2. deleteByHeadline("foo");
3. make sure repository was told to delete article

So, to generalize it:

1. stub
2. run
3. assert

Now, let's put it into words:

Interaction that is asking an object for data (or indirect input) is basically providing necessary input for processing. This kind of interaction is meant to be stubbed before running code under test (exercising the behaviour).

Interaction that is telling an object to do something (or indirect output) is basically the outcome of processing. This kind of interaction is meant to be asserted after running code under test.

Testing interactions like that is more natural and produces better code. Lessons learned from the old ways of testing interactions are implemented in Mockito:

Controversies

Above approach may seem controversial (quoting interesting para):

Then, when you do verify(...), you have to basically repeat the exact same expression you put in stub(...). This might work if you only have a couple calls to verify, but for anything else, it will be a lot of repeated code, I'm afraid

Basically, the controversy is about repeating the same expression in stub() and verify():

Do I really have to repeat the same expression? After all, stubbed interactions are verified implicitly. The execution flow of my own code does it completely for free. Aaron Jensen also noticed that:

If you're verifying you don't need to stub unless of course that method returns something that is critical to the flow of your test (or code), in which case you don't really need to verify, because the flow would have verified.

Just to recap: there is no repeated code.

But what if an interesting interaction shares the characteristic of both asking and telling? Do I have to repeat interactions in stub() and verify()? Will I end up with duplicated code? Not really. In practice: If I stub then it is verified for free, so I don't verify. If I verify then I don't care about the return value, so I don't stub. Either way, I don't repeat myself. In theory though, I can imagine a rare case where I do verify a stubbed interaction, for example to make sure the stubbed interaction happened exactly n times. But this is a different aspect of behavior and apparently an interesting one. Therefore I want to be explicit and I am perfectly happy to sacrifice one extra line of code...

Finally...

Mockito recognises the difference between asking and telling, hence stubbing is separated from verification. Stubbing becomes a part of setup whereas verification a part of assertions. This produces cleaner code and gives more natural testing/TDD. It doesn't increase code duplication as one might think. It's just one of the ideas implemented in Mockito to make the mocking experience a little bit better. It's not a silver bullet, though. Decent code is easily testable regardless of any mocking tools.

A common complaint with using mock objects is that interaction based tests ties your tests to the implementation details of the production code and interaction based tests are tracking the implementation of the method you’re testing. I felt this many times previously, every time I refactored my production code some of my tests seem to break even though, functionality of the object remained the same. Often mocks and interaction based testing are blamed for brittle tests. I have come to realize any brittleness exposed by interaction based tests is just a symptom of an over specified test or their is an underlying design issue because of a weak interaction model.

Interaction tests will be brittle and tied to the implementation if you dont specify interactions at the right level, and your tests will quickly let you know. After spending time doing some development in the Smalltalk world, i rediscovered that OO is all about message passing (object interactions). So a good OO model must have a good interaction model, with this in mind i have come to realize that the key to interaction based testing is specifying interactions (or conversations) between an object and its collaborators at the right level. An object should tell its collaborator what it should get done and not how it should do it. This drives us not to include even a hint of implementation detail when designing our interactions between the object under test and it collaborator, this forces us to create collaborator interface at an abstract enough so that no implementation details gets in the way, this leads to what is often called interface discovery of the collaborating objects, and is a great exploratory way to design the interface of collaborators and distribute responsibilities between objects and mocks are a vital tool to do this. This is what Steve Freeman and Nat Pryce have been telling us all along, but its only now I’m starting to understand this. However i also learnt not to use mocks everywhere, generally if I cannot model interactions between an object and its collaborator at an abstract enough level that made sense to the calling objects domain, it generally means i'm unable to define a clear role interface for the collaborating object, then in this case i would not use mocks at all, rather I tend to use a real object or a stub and test a cluster of objects together.
So what do I mean by “Specifying conversations between objects an abstract level”. I will try explaining by giving an example in the next post

The article is here

Scott has a follow up article on mocks (Mocks - It's a Question of When) discussing when you would choose to use mocking, which is here

Martin Fowler has an article about the art and science of mocking, called "Mocks Aren't Stubs" that is also well worth reading.

Now, how does Mocking come here? - My friend is still working on this database layer but he has given me already the Interface with which he is implementing the Database Class, so that I can make use of that and mock, as if that database layer exists and test my program against it.

What mocking framework I am using? - RhinoMocks

My friend told me that he is going to add events for each database operation, like InsertEvent, UpdateEvent, DeleteEvent so that they may be raised for each insertion, updation and deletion operations respectively.

For this post, to make it simple, let me take just the InsertEvent. Here is the class diagram,

And here is my Class which is going to make use of this Interface

I was pretty happy that my friend provided me an Interface to mock all the database activities, but I was really stuck on how do I test all those Events are raised!

Well, been using one of the best Mocking Frameworks around, RhinoMocks did provided a way to mock Events ;)

So, here is my test case,

[Test]

public void TestInsertEventRaised()

{

MockRepository fooDatabaseMock = new
MockRepository();

IFooDatabase

   fooDatabase = fooDatabaseMock.DynamicMock<IFooDatabase>();

fooDatabase.FooDatabaseInsertEvent += null;

LastCall.IgnoreArguments();

IEventRaiser
fooEventRaiser = LastCall.GetEventRaiser();

fooDatabaseMock.ReplayAll();

Foo myFoo = new
Foo(fooDatabase);

fooEventRaiser.Raise(this, EventArgs.Empty);

Assert.IsTrue(myFoo.InsertEventRaised);

}

RhinoMocks provides an interface called IEventRaiser which you can use to raise events!

Here is what we are doing,

• I am assigning null to the EventHandler and telling RhinoMocks that please do ignore the arguments in my last call. This helps us because we may associate our event to any Event Handler with different event arguments
• We initialize IEventRaiser by getting the last event, which in our case is FooDatabaseInsertEvent
• We pass on the Database object which is mocked to my Foo class to use
• And finally we raise that last event
• And do a simple Boolean check to see actually we did raise the event

Wasn't that easy ;)

You may complain that I have used the generalized EventArgs and completed this post. What about custom EventArgs?

No worries, that also takes the same route ;)

[Test]

public void TestUpdateEventRaised()

{

MockRepository fooDatabaseMock = new
MockRepository();

IFooDatabase

  fooDatabase = fooDatabaseMock.DynamicMock<IFooDatabase>();

fooDatabase.FooDatabaseUpdateEvent += null;

LastCall.IgnoreArguments();

IEventRaiser fooEventRaiser = LastCall.GetEventRaiser();

fooDatabaseMock.ReplayAll();

Foo myFoo = new
Foo(fooDatabase);

fooEventRaiser.Raise(this, new
FooDatabaseEventArgs("datbase",true));

Assert.IsTrue(myFoo.UpdateEventRaised);

}

The FooDatabaseEventArgs is our custom EventArgs.

I would recommend anyone reading this post to try out the sample posted below if you really want to understand what is happening ;)

You can download the sample here

There is this Test Spy framework I worked on lately. Unfortunately, it doesn't use 'test spy' metaphor at all. It talks about 'mocks' all the time. Some even say that the name of the library has something to do with mocking...

Was I just a foolish ignorant who didn't want to acknowledge different kinds of mocks. Ouch! I should say: Test Doubles. In case you haven't heard about Doubles: all those substitutes of real objects that make testing simpler or faster or more maintainable. I like them because they shrink the unit under test and make it easier to test.

I like simplicity. Introducing new concepts doesn't make things simple. Do I really need Double, Dummy, Fake, Mock, Spy and Stub to write decent code? On the other hand, I definitely need them to communicate how to write decent code.

At the back of my weird mind I used to think that Test Double breakdown was a bit disconnected from the reality where subtle differences are blurred (and the existing tools/libraries didn't really reduce the confusion). I tried to keep things plain but I reached the boundary: trying to keep things simple (and sticking to mocks and stubs) actually could have increased the confusion and made things complicated.

That's why I'm about to sort out Mockito terminology. Better late than never, right?

In all of my previous posts 'Mockito mock' should be read 'Test Spy'. But what's the Test Spy anyway? Or better: what's the difference between a Test Spy and a Mock? Both serve verifying interactions but the Spy is simple, lightweight and it gives very natural testing experience, close to good old assertions. Sounds interesting? Have a look at some of my previous rants or read this excellent post by Hamlet D'Arcy (don't miss Collaborator Continuum).

Let's get back to my favourite Test Spy Framework. Do you think following changes makes things simpler and easier to understand (I don't really know the answer...):

@Mock -> @Spy

mock(Foo.class) -> createSpy(Foo.class)

Competition is fierce and without proper (read: famous) name it will be difficult to get approved. But anyway: deadline for submissions is tomorrow. If you have any feedback about my session and you are willing to share it with me before end of tomorrow - I would be grateful.

I'm gonna present short version of this session during coming Last Thursday at Holborn office - see you there!

In state based testing (or return value testing) I assert that certain property has changed. I don't care if other properties have changed - unless I explicitly write assertions for them. Great benefit of this style is the flexibility of testing: I can write small, targeted test methods. Basically, I can test what I want.

In interaction based testing I expect an interaction to happen. Even if I don't care about other interactions I still have to expect them - to satisfy invasive mocks. This is how most mocking frameworks work and as a result, I cannot write small, targeted test methods. Basically, I cannot test what I want.

Some mocking frameworks are not invasive. Others offer tricks to reduce this problem - with various success rate and usually with side effects. Instead of jumping into examples let me ask you:

Does your mocking framework let you test what you want?

Expecting a single interaction in most mocking frameworks means: 1. this interaction must happen. 2. other interactions must NOT happen. Do you imagine if an innocent assertion of the state worked like that? Asserting one property meaning also asserting that NONE of the other properties have changed?

Let me rephrase my initial question: Why testing interactions has to be more defensive than testing state?

Is it because we fell in love with pre-programmed, intelligent mocks? Is it because of the way mocking frameworks are implemented? Or perhaps because of the strive to have a decent point of failure - mock can bark with unexpected interaction straight in the code so it's very easy to find it?

I'm not buying it. When it comes to behaviour verification, Mockito provides excellent point of failure. Also, Mockito can detect any kind of unexpected interactions. Oh, and Mockito lets me test what I want...

Mockito mocks are tamed. They don't make decisions for me. They don't know which interactions are expected or unexpected. I rule my mocks. I rule my code. And it pays back generously: code is cleaner and reacts better to changes.

By now, you've probably figured out that Mockito is not strictly a mocking framework. It's rather a spying/stubbing framework but that's a story for a different post.

My last post on Mock Objects explained briefly about what is Mocking and gave you an example. But that example is not explained and thought let me explain and how Mocking plays its part here.

So, revisiting that example,

[TestFixture]
public class AdminTests
{
    private MockRepository mocks;
    private EduAdmin eduAdmin;
    private Bl.IBLAdmin mockAdmin;
    private delegate bool ValidRegisterDelegate(Db.Admin entity);

    [SetUp]
    public void Setup()
    {
         mocks= new MockRepository();

         mockAdmin = mocks.DynamicMock<Bl.IBLAdmin>();
    }

    [Test]
    public void Check_Method_Register()
    {
        AdminEntity inputEntity = new AdminEntity();
        inputEntity.AdminId = “admin”;
        inputEntity.AdminPassword = “admin”;

        Db.Admin dbAdmin=new Educator.DataAccess.Admin
        {
            AdminId = “admin”,
            AdminPwd = “admin”
        };

        With.Mocks(mocks).Expecting(() =>
        {
            Expect
                .Call(mockAdmin.Translate(inputEntity))
                .Return(dbAdmin);

            Expect
                .Call(delegate { mockAdmin.Insert(dbAdmin); })
                .Callback((ValidRegisterDelegate)
                               ((entity) => { return entity.AdminId == “admin” && entity.AdminPwd == “admin”; }));

        }).Verify(delegate
       {
           eduAdmin = new EduAdmin(mockAdmin);

           eduAdmin.RegisterAdmin(inputEntity);
       });
    }
}

To explain the above example, consider this diagram

(Please consider the line separation, I will come to it later, Ignore the Tests)

So, as the diagram explains, we have,

1) EduAdmin which is our Service Layer (SL)

2) IBLAdmin which is our Business Layer (BL) Interface, and,

3) Database Layer (DL)

The BL interacts with DL to perform database operations and SL sends requests to BL in regard to what needs to be done.

So, what does the above example test function do? Here it is,

Revisiting again the definition of Unit Testing,

In computer programming, unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application.

The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. A unit test provides a strict, written contract that the piece of code must satisfy.

So, testing this RegisterAdmin function involves the use of BL as well DL (via the BL). And also from the first diagram, we do show that each layer is tested against their own tests. So, using Mock Objects, now we come down to,

Since we have mocked our BL, we can now write expectations on how it has to behave and what results it has to give for our Service Layer to work properly :)

To dig deep, we may have something like this,

Admin is a class that implements our Interface IBLAdmin and AdminEntity is business type and DB.Admin is a database type.With Mocking, we don't care about the Class but the Interface. EduAdmin is our Service Layer class and it has a function RegisterAdmin

So, to RegisterAdmin function to work properly, we have to see that the BL's Translate and Insert functions return proper results and those are nothing but setting expectations on our mock object which is IBLAdmin 8) . If you think slowly where we are, you will probably get what is Mocking ;)

Here is that part which sets expectations and tells what should be returned respectively

        With.Mocks(mocks).Expecting(() =>
        {
            Expect
                .Call(mockAdmin.Translate(inputEntity))
                .Return(dbAdmin);

            Expect
                .Call(delegate { mockAdmin.Insert(dbAdmin); })
                .Callback((ValidRegisterDelegate)
                               ((entity) => { return entity.AdminId == “admin” && entity.AdminPwd == “admin”; }));

        }).Verify(delegate
       {
           eduAdmin = new EduAdmin(mockAdmin);

           eduAdmin.RegisterAdmin(inputEntity);
       });

What does that ValidRegisterDelegate do? It checks whether the input parameters that is being used to invoke Insert function is of expected type and has expected values. Its more of a RhinoMocks feature, so once you start using it, you will get used to it :D . And RhinoMocks follows the Record and ReplayAll method where we set expectations means that we record something and once we say to verify, it replays all the set expectations when invoked.

The expectations we set are very simple. When the Translate function is called with an input parameter of type AdminEntity, return an object of type Db.Admin . Similarly for Insert function, except that we don't return anything.

In the Verify stage, we can see that we create a new instance of our SL by passing the BL Interface object. What are we doing here? Welcome to the world of Dependency Injection :D . We explicitly tell that - "Hey, here is my BL object which you have to use and please use this". We inject dependency here! So, now the BL object is already in the MockRepository and when we tell our SL to use this object, it means that its going to use the MockRepository object with expectations set on it 8)

I think now things are getting clear and you should be able to understand this diagram way better than earlier :) (which is also shown above)

Coming back to Dependency Injection - You may be wondering that so if my client uses this SL, will he always have to explicitly tell that this is my BL and use it? - NO. The way we overcome is using multiple constructors :)

public class EduAdmin
{
     private IBLAdmin blAdmin;

     public EduAdmin(IBLAdmin mockAdmin)
     { blAdmin=mockAdmin;}

      public EduAdmin() : this(new Admin())
     { }
}

I think thats self explanatory on what we do ;)

Hope this explained how we Mock 8)

If you have any doubts, please do leave your comments and I will try to answer them :)

What's wrong with it?

1. Codebase suffers. Test methods become noisy. I have to expect/record some interactions not because I want to test them but because mocks complain if I don't do it.
2. Doesn't give me a natural test-drive. I prefer when expectations become assertions and appear after execution - it's very intuitive.
3. Tests are fragile. Test driving new functionality that requires additional interaction often breaks all tests. Thanks to the aggressive nature of expect-run-verify.
4. Could give better failures. When expectation becomes assertion, failure shows exact line of code. No more deciphering exception messages - just click on first element on stack trace.
5. Could read better. Separation of stubbing and expectations reads really nicely.

Today I discovered MoQ - little mocking library for .NET. When I read how MoQ was invented I see many similarities with my own thinking process that pushed me to write Mockito.

MoQ uses C# 3.0 sugar like lambda expressions. Mockito is a java creature. Both don't like record/playback model. Mockito goes even further and abandons expect-run-verify.

Expect-run-verify...

Goodbye!

Let me enjoy most natural test-drive: as close to state based testing as possible. Expectations in Mockito are like assertions - good old friends of state based testing.

Java TDDer have several options these days:

1. Using hand crafted stubs/mocks: too much boilerplate, too many lines of code, chaos of stubs.
2. Using existing mock libraries: less some obscure exceptions it's all expect-run-verify stuff.
3. Mockito: just try it and tell me what you don't like about it :)

I know that many test-infected java people on this planet don't use mock frameworks. They code mocks/stubs from scratch because they find mock libraries too annoying. Mockito offers simplicity and flexibility of hand crafted mocks and yet eliminates so much boilerplate code. I encourage you to try it out.

Here I come with my own 10 commandments. I came up with those while doing research on mock frameworks (haven't you heard about Mockito, yet? it's the ultimate tdd climax with java mocks). I browsed so much of our project's test code that I feel violated now (codebase is nice, though).

1. If a class is difficult to test, refactor the class. Precisely, split the class if it's too big or if has too many dependencies.
2. It's not only about test code but I need to say that anyway: Best improvements are those that remove code. Be budget-driven. Improve by removing. The only thing better than simple code is no code.
3. Having 100% line/branch/statement/whatever coverage is not an excuse to write dodgy, duplicated application code.
4. Again, not only about test code: Enjoy, praise and present decent test code to others. Discuss, refactor and show dodgy test code to others.
5. Never forget that test code is production code. Test code also loves refactoring.
6. Hierarchies are difficult to test. Avoid hierarchies to keep things simple and testable. Reuse-by-composition over reuse-by-inheritance.
7. One assert per test method is a bit fanatical. However, be reasonable and keep test methods small and focused around behavior.
8. Regardless of what mock framework you use, don't be afraid of creating hand crafted stubs/mocks. Sometimes it's just simpler and the output test code is clearer.
9. If you have to test private method - you've just promoted her to be public method, potentially on different object.
10. Budget your tests not only in terms of lines of code but also in terms of execution time. Know how long your test run. Keep it fast.

Number #1 is my personal pet. Everybody is so test-driven but so little really care about #1 in practice. Best classes, frameworks or systems offer painless testing because they're designed & refactored to be testable. Let the code serve the test and you will produce delightful system.

Number #7 is a funny one ('Cos we need a little controversy). The whole world rolls in the opposite direction. Maybe I just don't get it... yet. Or maybe it's because I paired with young one-assert-per-test guy once. He cunningly kept writing test methods to check if constructor returns not-null value. If I had to play this game and chose my one-something-per-test philosophy I'd steal MarkB's idea: one-behaviour-per-test. After all, It's all about behavior...

Tinha um teste para um método, e nele, mockava um método de um outro objeto da seguinte forma:

historicoClienteDao.expects(once()).method("findByFiltros").with(1L, "nome", null, 3L).will(returnValue(historicos));

porém, este método ganhou mais um parâmetro e quando o adicionei, deu erro de compilação:

historicoClienteDao.expects(once()).method("findByFiltros").with(1L, "nome", null, 3L, true).will(returnValue(historicos));

pois o método with só recebe 4 Constraints.

Aí foi que percebi que ele também recebe um array de Constraints e então o "problema" foi resolvido da seguinte forma:

historicoClienteDao.expects(once()).method("findByFiltros").with(new Constraint[]{1L, "nome", null, 3L, true}).will(returnValue(historicos));

ps. a ferramenta usada neste exemplo é o JMock.

Syntax

Here is a what I think about mocking syntax:

• Let's keep it simple: interactions are method calls. There is no point in building sophisticated mocking language for method calls in Java. There is already a language for that. It's called Java.
• The less DSL the better. Interactions are just method calls. Method calls are simple, DSL is complex.
• No Strings for methods. I spent more time reading code than writing it. Therefore I want the code to be readable. String literals pretending to be methods cannot compete with actual method calls. Even IDEs decorate literals differently so my mind will always adopt the real method call quicker than any literal trying to impersonate a method.
• No anonymous inner classes. They bring more indentation, more curly brackets, more code, more noise. Did I mention that I spent more time reading code?
• Painless refactoring. Renaming a method should not break my tests.

That's why I really like the syntax of EasyMock.

Long journey from EasyMock to Mockito

I was brought up on EasyMock. Normal kids got milk I got classes to test. Over the years on different projects I saw idyllic world of hand crafted stubs being overthrown by EasyMocks. On other project, jmock was doing fine until he got a Chuck's roundhouse kick to the face by EasyMock. Finally, I saw resentment to EasyMock and triumphatic comeback of hand crafted stubs... Sometimes the resentment to EasyMock was a bit naive ("My class has 10 dependencies and is difficult to test. Therefore EasyMock sucks"). Sometimes it was clearly righteous...

Here is what I wanted to achieve with Mockito so that it suits me better in test-driving code the way I like:

Focused testing. Should let me focus test methods on specific behavior/interaction. Should minimize distractions like expecting/recording irrelevant interactions.

Separation of stubbing and verification. Should let me code in line with intuition: stub before execution, selectively verify interactions afterwards. I don't want any verification-related code before execution.

Explicit language. Verification and stubbing code should be easy to discern, should distinguish from ordinary method calls / from any supporting code / assertions.

Simple stubbing model. Should bring the simplicity of good old hand crafted stubs without the burden of actually implementing a class. Rather than verifying stubs I want to focus on testing if stubbed value is used correctly.

Only one type of mock, one way of creating mocks. So that it's easy to share setup.

No framework-supporting code. No record(), replay() methods, no alien control/context objects. These don't bring any value to the game.

Slim API. So that anyone can use it efficiently and produce clean code. API should push back if someone is trying to do something too smart: if the class is difficult to test - refactor the class.

Explicit errors. Verification errors should always point stack trace to failed interaction. I want to click on first stack element and navigate to failed interaction.

Clean stack trace. Part of TDDing is reading stack traces. It's Red-Green-Refactor after all - I've got stack trace when it's red. Stack trace should always be clean and hide irrelevant internals of a library. Although modern IDE can help here, I'd rather not depend on IDE neither on competence in using IDE...

EasyMock is a decent piece of software, credits go to kick-ass people who wrote it. I had to fix it, though :). I've even submitted some patches to address inflexibility of mock modes but they never made it to the trunk. I had more radical ideas so I forked the project removing, refactoring and rewriting loads of code. Enjoy.

(I refactored this page a since I wrote it, precisely I got rid of lengthly mock framework comparison).

O nome do cara é JMockit

Bem, o meu exemplo é bem simples:

Criei uma classe que tem somente um método estático, é esta classe que quero mockar:

public class ClasseUtil {

public static int metodoEstatico()
{
return 1;
}

}

Então, uma classe que utiliza este método:

public class ClasseFuncionalidade {

public static int metodoLocal()
{
return ClasseUtil.metodoEstatico();
}
}

Por fim, a classe de teste:

public class ClasseFuncionalidadeTeste{

public static class MockClasseUtil{

public static int metodoEstatico()
{
return 0;
}
}

@Before
public void prepare(){
Mockit.redefineMethods(ClasseUtil.class, MockClasseUtil.class);
}

@After
public void finalize(){
Mockit.restoreAllOriginalDefinitions();
}

@Test
public void metodoLocal(){
assertEquals(0, ClasseFuncionalidade.metodoLocal());
}

}

Perceba que criei uma outra classe (inner class) chamada MockClasseUtil, com um método (metodoEstatico) de mesma assinatura do método da classe ClasseUtil, porém o retorno é diferente (No original é 1 e no falso é 0).

Redefino os métodos da classe real pelos da classe mock:

@Before
public void prepare(){
Mockit.redefineMethods(ClasseUtil.class, MockClasseUtil.class);
}

Se fosse no JUnit3, poderia usar o método setUp para invocar o redefineMethods.

E para voltar "ao normal":

@After
public void finalize(){
Mockit.restoreAllOriginalDefinitions();
}

A única dificuldade foi "ver" que o comando "-javaagent:jmockit.jar" deve ser passado como parâmetro para a JVM:

No eclipse é só fazer isso, na hora de rodar o teste:

ou isso, para rodar com test suite ou qualquer outro lugar:

Baixei o jmock-cglib-version.jar, como diz no link abaixo:

http://www.jmock.org/jmock1-cglib.html

e funcionou.

A única limitação é que não pode ser uma classe final.

JMock acaba de recuperar seus pontos.

Thanks, Nat Pryce.