Test-driven Development As If You Meant It Reviewed—The Problem
Published:
This article is part 2 in a 5-part series.
- Part 1: Test-driven Development As If You Meant It Reviewed—Introduction
- Part 2: This article
- Part 3: Test-driven Development As If You Meant It Reviewed—First Steps
- Part 4: Test-driven Development As If You Meant It Reviewed—Interesting Moments
- Part 5: Test-driven Development As If You Meant It Reviewed—'Normal' TDD
This article was written with and is also published by Mark Withall.
The Problem: Noughts And Crosses (Tic-Tac-Toe in American)
In Keith Braithwaite’s original exercise, the problem tackled was Noughts and Crosses. To allow us to compare with other attempts out on the Internet, we are going to tackle the same problem. We intentionally didn’t fully define the problem in advance; except to focus on the game management aspects, rather than any AI components.
Language/Library Choices
We decided to do the exercise in Python (2.7), as it was the language with which we had the highest average skill level. We used pytest and mock for testing and pytest-xdist to allow the test to run continuously in the background and keep us honest.
Code was written in Vim (because, y’know, it’s better than [REDACTED], etc.). YouCompleteMe and syntastic were used for autocompletion and static analysis to speed things along. We did try the rope refactoring tools briefly but they aren’t currently robust enough. We must take some time to look at some of the issues we had at some point to help get it up to scratch; as life isn’t worth living without refactoring tools.
The whole was wrapped up in virtualenv to make it easy to get up and running with a standard environment.
Methodology
We started with some TDDAIYMI ‘dry runs’ to get the hang of using this technique as, whilst it seems very-much like TDD on paper, it ‘feels’ quite different to use it. We then carried out our ‘control’ exercise of ‘traditional’ TDD and finally followed this up with a serious go at the problem in TDDAIYMI style.
For the experiment, we decided to commit after each stage of the RED-GREEN-REFACTOR cycle, to allow the easiest replay of what happened. In real life, we probably wouldn’t choose the commit after a RED stage, to keep the repository in a working state as far as possible (e.g. to allow binary search of the history).
During the exercises we were looking out for:
- Similarities between the two approaches
- What worked with TDDAIYMI
- What didn’t seem to work
- How we feel TDDAIYMI might be improved
- General lessons learnt
Next Time
We finally get the flip on with it.
Tags
programming and tdd