For someone like me, new to development, it sounds really strange to write a test before having a function or product ready. But anybody at Makers Academy is a 100% convinced that the so called technique of “Test Driven Development” (TDD) is absolutely essential for writing good, maintainable code.
What it is and how it works (non-technically spoken)
In TDD developers at first break their problem down into objects and actions. In our first week’s project we are dealing with the famous London „Boris Bikes”. Those can be rented and occasionally they have to be fixed. There are some more objects like a van that comes to fetch broken bikes and so on… but let’s focus on those bikes at first.
The project is not about building a shiny website on which people can rent bikes. It’s about inventing a model that reflects those processes in Ruby-code. I can make up a (code-)bike by writing:
class Bike
end
bike1 = Bike.new
Between “Bike” and “end” I can later on define, that our virtual bikes are initially in good conditions, until someone calls my newly invented “method” called “break!“ that breaks the bike (even though you might be interested in how people break the bikes – that’s [again] not part of the game). Building those objects and features doesn’t seem to be so difficult at first. But actually it’s really hard to find the details, the program should in the end focus on. I found myself thinking about the users and what they do when their bikes break somewhere on the way. But that’s not part of my project.
Back to TDD. Before we are allowed to invent our tiny complexity-reduced world, our coaches Stephen and Mihai expect us to write tests that will check the code we write.
Irritating „natural language“
I don’t know many developers but the ones I have heard talking about code were really excited about programming language that actually reads like English. From my perspective this is a very silly thing. I want to learn a language that my computer understands but this language turns out to be some awkward dialect of English. It’s good that I can guess what a method called “concatenate“ does or what happens when I use operators like „if“, „else“ or „unless“. But there are so many ways to say that the docking station for bikes is full that are easier to guess than that one:
it 'should not accept a bike if it\'s full' do
fill_station(station)
expect(lambda { station.dock(bike) }).to raise_error(RuntimeError, 'Station is full')
end
I trust them…
Stephen would most probably say that this code needed some refactoring to be better readable and that there are a 1000 different ways to “say” this in code. I have decided to trust him and the other teachers. Obviously people can learn how to read and write this language fluently. And I really want to learn that as well.
“know_code? if false – keep_reading. else ‘hurray!’“