This week I dug the book Test-Driven Development By Example out of my closet. In the book a case is presented, a customer working with a bond portfolio management system wants to add different currency bonds. It is up to you to check if the system can handle that.

This books guides you through a scenario using TDD in Java. Although halfway through it switches to Python because it uses the xUnit testing structure. What is xUnit you may ask, as I did as well.

xUnit is the collective name for several unit testing frameworks that derive their structure and functionality from Smalltalk’s SUnit. SUnit, designed by Kent Beck in 1998, was written in a highly structured object-oriented style, which lent easily to contemporary languages such as Java and C#.

Following its introduction in Smalltalk the framework was ported to Java by Kent Beck and Erich Gamma and gained wide popularity, eventually gaining ground in the majority of programming languages in current use. The names of many of these frameworks are a variation on “SUnit”, usually replacing the “S” with the first letter (or letters) in the name of their intended language (“JUnit” for Java, “RUnit” for R etc.). These frameworks and their common architecture are collectively known as “xUnit”. From wikipedia

However I do not work with Java, but I do with other languages and I have a couple languages that I want to learn about. What a great way to combine learning TDD with learning more about a language.

Issues

I started of with Go, not realizing it isn’t OOP like Java,which stopped me dead in my tracks around chapter 7 because of objects and classes not existing in Go. Defeated I searched for another language I could try it with. Thinking about which other projects I am working on I thought about my Flutter app. Wait a minute, Flutter uses Dart which is OOP. So I started the book again, using Dart this time around.

Using a different language than what the examples provide forces me to research Dart and how to implement the examples from Java. For example: The tests in Dart don’t use AssertTrue but expect() in which you give a second parameter true or false.

Java

assertTrue(new Dollar(5).equals(new Dollar(5)));

Dart

expect(Money.dollar(5).equals(Money.dollar(5)), true);

Another issue I ran into was creating a new Integer object. In the part where you have to add rates to a bank object, the book uses this function

void addRate(String from, String to, int rate) {
	_rates.putIfAbsent(new Pair(from, to), new Integer(rate));
}

This fails in Dart as there is no method for Integer. This combined with the fact that the Java example used a HashTable where Dart uses a HashMap which requires the key to be a function.

Map<String, int> scores = {'Bob': 36};
for (var key in ['Bob', 'Rohan', 'Sophena']) {
  scores.putIfAbsent(key, () => key.length);
}

Also had trouble getting the value out of the HashMap by using the same key I just created. Funny thing is when I searched stack overflow for a solution I found a question using the same example

Conclusion

The book helped me get a handle on writing tests and introduced the idea that you can start with really small steps. This is helpful for me as I have a few projects without tests that I really should update before going further. Mainly my [Flutter}(https://vitominheere.com/projects/flutter_grip_trainer/) project and an older graduation research project which I want to rewrite in the future.

The instructions were clear and easy to follow even when doing the exercises in a different languages. After a couple of chapters the speed was ramped up and it sometimes was harder to understand what to add where. But with a bit of trying on my own and some help from the compiler I could find out what to change. Overall it gave me more insight in writing test and an in depth look at Dart.

Part 2

The code of this chapter was also able to be done with two files, one for the tests and one for the classes used. I found this chapter to be less clear, even though python is my main language. Perhaps it was because it was more abstract, the first chapter had a story around it that was easier to visualize. It gave me a better understanding in how tests are actually ran and what happens in the background. Turns out it is not an awful lot and I was surprised it was that little. Of course this was not a full implementation, the author left out a few parts which you could add on your own. I like these kind of challenges as it makes you think about what you just learned and try to apply it in a different way. Just following along with instructions does not teach you very much.

Because this chapter covered Python I did not run into much issues with the code itself. I could understand all of it and even applied some more Pythonic ways to it. Unfortunately this makes it harder for me to tell you about some issues I had, it was much more straight forward in that case than the first chapter. Nevertheless the added commentary helped me understand the xUnit framework a bit better.

Part 3

The last part goes into depth about the ideas behind testing and some testing design patterns. This builds on what you learned in the book and adds some new patterns as well. I had to read through this pretty quick as I had to return the book in a few days.