I’ve been playing a bit with Swift and iOS on my free time. Being a TDD affictionado I was happy to find Cory Foy’s article on Test-Driven iOS Development with Specta and Expecta. Although it is actually for Objective-C it was an excellent introduction on how to get started with TDD in that environment.
TDD Series Part 1 – First write a test? Not.
I’m an avid TDD’er. I just love it. I teach it a lot. To those who think they know and to beginners. And it is not so easy to grook. And maybe it’s an acquired taste. I feel it is an essential tool in a programmers tricks, and am amazed that so few actually know it well enough. And that there are still those that actively denounce it. It is not universally applicable, true, but in my mind, if you consider yourself a programmer, you must know how to do it fluently. Period.
In a few installments I plan on showing the way I do it. And possibly allow a few others to acquire the taste, and some proficiency. Maybe even some more seasoned coders out there will pick up some tricks. Or teach me some…
For me TDD is very much about three words: focus, confidence and pace.
TDD done right allows, and forces, you to focus. We all know that focus is key to progress. But also that you usually only manage to focus on smaller, clear, things. Big, fuzzy things are hard to pinpoint, to focus on and of course, to get any progress on. So the first step to TDD is partitioning into smaller chunks.
Let’s get started. You have probably read, or heard, that the first thing that you should do is write a test.
Wrong.
Continue reading “TDD Series Part 1 – First write a test? Not.”
Assert-first, Backwards directed, Completion assisted Coding
Testdriven development, TDD, is a well-known technique to be able to focus on the tiny next step of specific functionality to implement. My experience from watching a number of coders in our Dojo’s, and from my own work, is that even though focusing on the test is the idea, it is easy to get side-tracked. All the little details that need to be set up before arriving at the assert statement at the end of the test are distracting. Instead of focusing on the feature the coder starts thinking about which variables are needed, their names, are there any constant values, which handy functions do we need to write. This sequential mode of coding is particularly obvious in more inexperienced programmers and splits the focus. Trying to keep many details in your head at the same time as trying to maintain the direction of the test is hard.
I’m a mediocre programmer and I have a hard time keeping all the details in my head. I need help to focus on what is to be achieved. TDD has been a tremendous help and is my safety net. But to get one step further I have started to use a technique, or rather coding style, that starts with writing the assert-statement first. Yes, just the assert. This helps me think about what the test should actually test before I think about how to set up the test. Let’s call that “Assert-first coding”.
In the same way as for the assert statement in the test, you can start with the end result in the production code. E.g. the return statement in a function is the required goal. Once the return statement is in place we can think about, and implement, what is required to get statement to compile. Step by step we can work our way backwards until we have the complete function. Let’s call that “Backwards directed coding”.
Espescially in typed languages and with modern IDE:s like Eclipse, it is possible the use the Code Completion and Quick Fix features to quickly and easily fill in the gaps and create the pre-requisites to get the assert or return statement to a runnable state. Let’s call that “Completion assisted coding”.
If you combine these techniques you get a style that could be called “Assert-first, Backwards directed Completion assisted Coding”, ABC;-) Thanks, Joakim Holm for the name. (I initially called it “ACBC”.)
I’ll get back with some screen captures to show what I mean.
Bowling Kata “solution”
One of the most famous katas (excercises) for TDD (test-driven development) is the Bowling Kata. There are some sites that describe the Kata, which has the following “stories” as input:
- A bowling machine want to report the number of pins the player strikes down for every roll the player does
- A bowling player want to see the resulting score of a completed game
It is actually a rather simple Kata, but never the less allows for demonstration and training of some TDD tasks and strategies. But of course you need to know the bowling rules…
We have used the Bowling Kata for our Coder’s Dojos, and have learned a lot from it. The following is a recording of one of my solution to it :
Refactoring with red bar?!?!?
We have been running the Coder´s Dojo Sweden during the autumn, and yesterday we started the spring sessions. One of the interesting observations that we have made is a follow-up on a comment that I made on Robert C. Martins page about the Bowling Kata.
The observation was that if you follow the rules “refactor only in the green” (you may only refactor while you have working and passing tests as your life-west) and “only develop new functionality in the red” (while you have a failing test for that functionality), you will inevitably end up with a situation that your new functionality driving test case forces a re-design, right?
It may be obvious to most of you out there, but we couldn’t find a single mention of how you are supposed to solve that predicament. We surely do not want to do a redesign with a failing test, the green bar is our safety net. Of course you could keep an eye on which tests are causing the red, but that is tedious and error-prone.
What seems logical is to temporarily get rid of the failing test, which you can easily do by commenting out the failing test. Simple, right? And possibly second nature to seasoned TDD:ers. But if so, why has there been no developmen of tools support for this? I could easy envision a “disable test” feature in the Eclipse/JUnit GUI…
“Pairing with Thomas”
I came across Ron Jeffries book Extreme Programming Adventures in C# on Agile Alliance members page, a book which he thinks should be called “Pairing with Ron”. It’s about the development of a small XML editing tool he did. But it describes every little test, refactoring and other anecdotes that are relevant.
I thought this to be fairly interesting, and since I have just started on a similar journey I though I’d start some kind of log of it here. Of course I have already done some basic things so I try to make this log catch up quickly.
I am trying to build an Object Application Modeller. The basic functionallity is to be able to define classes with attributes, relations and views. I have seen many applications where this is actually the basic functionallity, so maybe this tool exists already but since it’s a journey the goal is not the value, the journey in itself is.
The trick is to be able to “generate” an application from these definitions, with support for persistence of the instances of the classes and relations of course. *AND* with the possibility to upgrade, which will introduce the need to refactor the persistent storage (a.k.a database) on upgrade.
I’m sorry that I will not be able to remember all the steps I have already taken, but here are the initial list of User Stories:
- Define and Delete a Class
- Save an Application Definition and Restore it
- Add a (String/Integer type) attribute to a Class and Delete it
- Create instances of the defined classes (implies deploying the Application)
- Display instances as a table with attibutes
- Select which attributes to show
- Sort and filter data according to specific column
- Define Relations with attributes between specified Classes
- Show instances with attributes in a tree using a specific relation showing attributes
- Show instances with all relations
- Deploy an updated Application Definition to an existing Application
So I started with a test that creates a Dictionary, adds a Class to it and then looks up that same Class. No problems there, implemented the Dictionary as an ArrayList which took Class.
Then save and restore, almost as straight forward. Decided to use a simple text file with one line per Class.
Then, GUI! Since many have talked about thin GUI:s I first decided to use the Eclipse Visual Class editor to just add a simple GUI on top of the functions. That was just somewhat successful. And it felt bad. Why couldn’t I do TDD on the GUI?
Having introduced Automatic Testing of the webapplication in my current project I knew there where a multitude of GUI testers, but I surely did not want to go down the path that lead us to Mercury Quicktest Professional!!
But I found Abbot, “A Better Bot”! It drives and inspects Java GUI, and JUnit functionallity to boot! So I added some tests to drive my GUI components, and of course I had to refactor those a bit to make the testing easier.
So now I could add tests to drive adding attributes. And since I implemented those as ArrayLists too I refactored out an ItemList to hold Items which became a super class to Class and Attribute.
I have just added a test to drive adding attributes from the GUI. The first test is to select a Class, press the Edit button and ensure that an “Edit Attributes for Class” window appears. And that’s where I am now.
To be continued…