Revisited Kata: Using Midje's defrecord-openly to mock a protocol in Ohce

Several weeks ago I did the Ohce kata in Clojure using outside-in TDD with Midje (as I explained in a previous post).

In that post I said that I hadn't used Midje's defrecord-openly and provided macros and had instead decided to write my own code to capture the arguments with which the functions of the Notifier protocol implementation were being called because:

... I didn't like having to use defrecord-openly in production code.

Well, I was wrong!

It turns out that it is not necessary at all to use defrecord-openly in your production code in order to mock a protocol.

I understood it thanks to this answer in Stak Overflow: Mocking Clojure protocols.

The only thing I needed to do was to use defrecord-openly to create a fake implementation of the Notifier protocol inside the test code like this:

and then write the tests against this unimplemented fake.

This are the new Ohce tests:

As you can see it's very easy to use Midje's defrecord-openly to mock protocols.

I just misunderstood Midje's documentation the first time I tried to do it...

Interesting Paper: "Why should physicists study history?"

I've just read this wonderful paper by Matthew Stanley

• Why should physicists study history?

This is a gem full of wonderful ideas about diversity, group dynamics, critical thinking and the pursue of knowledge that I think are also valuable to software development and, probably, to any team or community effort.

Interesting Talk: "Components with Clojure"

I've just watched this wonderful talk by Malcolm Sparks

• Components with Clojure

Revisited Kata: Listening to the tests to improve the design of Ohce

A couple of weeks ago, I did the the Ohce kata in a Barcelona Software Craftsmanship event (I wrote a previous post about it).

I wasn't happy with the resulting tests for the Ohce class:

What I didn't like about the tests was that they weren't independent from each other.

When I started doing TDD, they were independent, but as soon as I introduced the loop to request more user phrases, I had to stub a call to the PhraseReader in each test that returned the stop phrase to avoid infinite loops.

This made the tests to be very coupled to Ohce's implementation:

Another problem was a violation of the Law of Demeter caused by asking the Phrase value object, being returned by the PhraseReader, if it was a palindrome.

This made it necessary to stub some calls to the PhraseReader returning dummy phrases to avoid getting null pointer exceptions.

These problems in the tests were a signal of problems in the design (see What the tests will tell you).

I think there were two main problems:

• Ohce code had too many responsibilities.
  • Controlling the dialog with the user.
  • Responding to the user inputs.
• Ohce code was too procedural.

How could I fix them?

Well, I started thinking about a metaphor in which Ohce was having a dialog with the user and responded to each user phrase, and how this dialog might be infinite unless the user made it stop by introducing an stop phrase.

This made me realize that there were some missing abstractions.

So I decided to explore this metaphor of an infinite dialog comprised of responses to each user phrase:

InfiniteDialog only had the responsibility of going on reading and responding to the user phrases until told to stop.

Going on with the metaphor, each of those responses to the user input might be seen a sequence of two responses: one that reversed the user phrase and another one that celebrated when the user phrase was a palindrome.

To compose several independent responses, I used a decorator:

Then I just needed to separately code each concrete response:

Notice how all the tests in InfiniteDialogTest, SequenceOfResponsesTest, ReversingResponseTest and PalindromeResponseTest were just adaptations of tests that were originally in OhceTest, only that now they were much more focused and simple.

I regard this as a sign of design improvement.

Finally, I refactored the code to make Ohce start using the InfiniteDialog by applying parallel change. It was a very smooth refactoring during which no tests were broken.

I think that this smoothness was a special case, because all the expectations in old Ohce's tests were also satisfied using InfiniteDialog. Using InfiniteDialog just added some new layers of abstraction over old Ohce's collaborators, but behind those layers the old collaborations were still happening.

In a different case, I might have probably broken some Ohce's unit tests, but that wouldn't have been a problem because the behavior would have been still protected by the end-to-end tests. So, I could have just deleted the broken unit tests and written a new one for the collaboration between Ohce and Dialog.

These were the new tests for Ohce:

And this is its new code:

We've seen how listening to some problems in Ohce's tests, led me to find some design problems, that once fixed produced much more focused, clearer and less coupled tests, and how having used mocks didn't suppose any problem at all during the whole refactoring process.

--------------------

You can find all the code in this GitHub repository.

Interesting Talk: "Managing One of the World's Largest Clojure Code Bases"

I've just watched this very interesting talk by Donevan Dolby

• Managing One of the World's Largest Clojure Code Bases

Kata: Parrot Refactoring in Java (recorded)

I've recorded myself doing the Parrot Refactoring kata in order to be able to later watch me and detect problems to correct.

This is the recording of what I did:

• Parrot Refactoring Kata

If you decide to watch it, please do it at 2x speed (I still write slowly).

These are the commits after every refactoring step.

You can see the code in this GitHub repository.

Five years ago in Garajeando... (TDD)

This is a post titled "Learning TDD" from 5 years ago that I found last night:

TDD stands for Test-driven development and quoting the Wikipedia definition is

"a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards".

I've been hearing a lot about it since I started programming again. That aroused my curiosity and I'd like to learn how to use it.

These are the resources that I plan to use:

• I've ordered Test Driven Development: By Example, a book written by Kent Beck.
• I've found a wonderful series of videos by James Shore: Let's play: TDD.
• There's also a book in Spanish about TDD written by Carlos Blé that you can download for free: Diseño ágil con TDD.

It was very nice remembering when I started this path.

After a lot of practice I'm still learning new things about TDD and enjoying it.

An example of using dynamic fact descriptions in Midje

I had these tests written in Midje which had some duplication:

but were providing a nice level of feedback when there was an error:

In my first attempt to remove the duplication in the facts:

I lost the level of feedback the original tests had. It didn't tell which sorter was failing:

By using dynamic fact descriptions (notice the use of the :midje/description metada):

I was able to keep the original level of feedback and still remove the duplication:

Interesting Talk: "Software Design and the Physics of Software"

I've just watched this really interesting talk by Carlo Pescio

• Software Design and the Physics of Software

Kata: Ohce in Clojure using outside-in TDD with Midje

I did the Ohce kata in Clojure using outside-in TDD with Midje.

I started by writing a nearly end-to-end test for the scenario of running ohce during the morning:

In this test I used Midje's unfinished and provided macros to stub the hour-fn and read-input functions and with-out-str to capture the any printed lines.

Using Midje's future-facts macro I avoided seeing this acceptance test failing every time the tests were run, instead I saw a reminder message like this one:

Next I started testing ohce at the unit level. These are the resulting facts:

For these facts I used a fake implementation of the Notifier protocol:

which captured the arguments with which the functions of the protocol implementation were being called:

I could have used Midje's defrecord-openly and provided macros instead but I didn't like having to use defrecord-openly in production code.

Update:
The statement above is wrong. It is not necessary at all to use defrecord-openly in your production code in order to mock a protocol. See how it's done in this other post: Revisited Kata: Using Midje's defrecord-openly to mock a protocol in Ohce.
--------------------------

Another thing to notice in that test is the use of Midje's metaconstants to avoid the facts knowing about the "shape" of data (where it was possible to do it).

Well, those facts lead to the following code:

Then I started applying TDD on the next level to write ConsoleNotifier, an implementation of the Notifier protocol:

and the select-greeting function (select-by-day-period in this case):

Once those tests were passing, I just had to inject a ConsoleNotifier record and the select-greeting function into ohce to make the acceptance test pass:

I also added two other scenarios (running ohce during the afternoon and during the night).

A curious thing to notice is that I couldn't use partial with select-greeting if I wanted the provided macro to work with hour-fn, that's why I used a lambda instead. Due to the same problem I also had to wrap the read-input function inside a lambda.

Then to be able to really run ohce on the console I just had to write a real hour-fn function (tested on the REPL):

and create a -main function (read-input is just the Clojure's read-line function):

This is an example of running ohce:

I committed after each passing test and each tiny refactoring, so that you can follow the process if you feel like. You can check the commits step by step here.

You can find the resulting code in this GitHub repository.

Doing this kata helped me to learn a lot of new things about Midje.