Counters in the InOrder world: times()

If you are reading this post, probably you had already a glance to my previous post about the Counters. You have probably noticed that the Counters functionality was somehow incomplete. Some of the counter where available for the classic verification but not for the ordered verification.

But not anymore.

Apex Mocks it’s getting more flexible and powerful allowing you to specify strict and loose counters in the inOrder verification.

Let’s go through them one by one and discover their power.

times()

((ISoftwareDeveloper) inOrder.verify(
    mockProductiveDeveloper, MY_MOCKS.times(15))).drinkCoffe();

You can immediately understand that our software is having quite a lot of coffees during the day. But there are some details that need to be mentioned. Let’s have a look at this snippet of pseudo code.

1 softDev.writeSomeCode();
2 softDev.writeSomeCode();
3 softDev.drinkCoffe();

4 softDev.writeSomeCode();
5 softDev.blameSlowNetwork();

6 softDev.writeSomeCode();
6 softDev.writeSomeCode();
7 softDev.gitCommit();

We all are productive developers, so let’s concentrate on the writing of the code, and verify how many times the code has been written.

The times allows us to check how many times the method has been called, and this verification is not strict. What does it mean in code? If we write those verify as separate tests

((ISoftwareDeveloper) inOrder.verify(
    mockProductiveDeveloper, MY_MOCKS.times(2))).writeSomeCode();

((ISoftwareDeveloper) inOrder.verify(
    mockProductiveDeveloper, MY_MOCKS.times(1))).drinkCoffe();

and

((ISoftwareDeveloper) inOrder.verify(
    mockProductiveDeveloper, MY_MOCKS.times(3))).writeSomeCode();

((ISoftwareDeveloper) inOrder.verify(
    mockProductiveDeveloper, MY_MOCKS.times(1))).blameSlowNetwork();

they would both pass.

Yep, you read correctly, they both pass. Why? It’s related to the instances consumed in the verification. For each test, the inOrder goes through all the instances of the mock that we are verifying and sequentially consumes the available invocations.

The first tests first check that writeSomeCode() method is called twice, then looks for the drinkCoffe() and it’s happy. Quite straight forward.

The second Test instead is a bit more tricky. This needs three instances of the writeSomeCode(). Starting from the beginning it has two instances, then have the drinckCoffe() in the middle that is ignored and then it finds the third. After that, the instance available to be verified is blameSlowNetwork().

I’m sure you can tell me how many available instances there are for the writeSomeCode() before our dev would final commit the work on git.

On the other side

((ISoftwareDeveloper) inOrder.verify(
    mockProductiveDeveloper, MY_MOCKS.times(4))).writeSomeCode();

((ISoftwareDeveloper) inOrder.verify(
    mockProductiveDeveloper, MY_MOCKS.times(1))).gitCommit();

and

((ISoftwareDeveloper) inOrder.verify(
mockProductiveDeveloper, MY_MOCKS.times(3))).writeSomeCode();
((ISoftwareDeveloper) inOrder.verify(
mockProductiveDeveloper, MY_MOCKS.times(1))).blameSlowNetwork();
((ISoftwareDeveloper) inOrder.verify(
mockProductiveDeveloper, MY_MOCKS.times(1))).writeSomeCode();

both would fail.

One last detail, the default verification for the InOrder is now “times(1)”. that means that I could happily not specify in my examples whether instead, I kept for readability.

As you can see the power and the flexibility of the InOrder verification have grown with this new counter adding a functionality that was some how missing.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s