tdd

Using literals in your tests can have some advantages, such as, readability and traceability. While this is true when the data are simple, it's less so when the data are nested, complex structures. In that case, using literals can hinder refactoring and thus become an obstacle to adapting to changes. The problem with using literals for complex, nested data is that the knowledge about how to build such data is spread all over the tests. There are many tests that know about the representation of...

In the last Clojure Developers Barcelona meetup, we started to use re-frame to animate in the browser the code to evolve cellular automata that we wrote some weeks ago. We managed to make a rough version but we didn't have time to test it and make it nice. When I got home I redid the exercise from scratch using a mix of TDD and REPL Driven Development. First, I coded a couple of evolution rules. These are their tests: and this is their code: Next, I coded the cellular automata evolution, thes...

I recently did the Scrabble sets kata in Clojure. I used a mix of a bit of TDD, a lot of REPL-driven development (RDD) following this cycle: Write a failing test (using examples that a bit more complicated than the typical ones you use when doing only TDD).Explore and triangulate on the REPL until I made the test pass with some ugly but complete solution.Refactor the code to make it more readable. I'm founding that this way of working in Clojure is very productive for me. These are the tests I...

At this week's Clojure Developers Barcelona meetup, we did the Cellular Automata kata in Clojure. We did mob programming and used a mix of TDD and RDD. This is the code we wrote: First, the tests using Midje for the rules 30 and 90: and the tests for the evolution and rendering of automata: This is the corresponding code for the rules: and for the automaton evolution and rendering: Printing on the REPL the result of rendering the Rule 90 automaton evolution during 15 steps, we obtain a nice...

In last week's Barcelona Software Craftsmanship Dojo we did the Varint kata created by Eric Le Merdy. Since I was facilitating it, I couldn't code during the event. Once I got home, I did it using Clojure. These are the tests using Midje and Clojure test.check libraries: and this is the resulting code: I used a mix of a bit of TDD, a lot of REPL-driven development (RDD) and some property-based testing. Basically, the cycle I followed was like this: Write a failing test (using more complicated...

I did the Printing Account Statement subset of the Bank Account kata in Clojure using Component and Midje. I started the kata in a Barcelona Clojure Developers event. The truth is that, since I was learning how to use the Component library, I didn't use TDD. Instead I worked on the REPL to get everything in place and make it work. Then I wrote the tests I would have liked to write if I had used outside-in TDD with Midje. I find that, when I'm learning something new, it works better for me wha...

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...

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 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...

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 testin...