#test-driven

It allows the infrastructure team to have confidence that their configuration changes are being applied as intended across many different systems, and having the intended effect. This allows the whole system to be trusted, and then updated without fear for introducing breaking changes or otherwise causing instability.

Galations 6:3,4 (NIV)

Use migrations to create & modify the database. Use code-first generation to verify your migrations.

Known as Code-First (or CF), specifying database tables using Plain Old C# Objects (POCOs) is elegant. It provides basic Object Relational Mapping and the classes can be reused in other ways. It is hard to let go of this feature.

But, schemas were made to be broken. So we use Migrations to stay Agile despite database changes.

Unfortunately CF-generation and Migrations do not work well together. Creating tables for the first time seems fine with CF, or if migrations have already been done. But, what if you need to apply migrations after CF creation? The Migrations framework will not know what version the deployed schema is on.

CF ensures that your classes match your database design. Migrations provide no such guarantee. CF is declarative (preferred), while Migrations are procedural.

Therefore, I recommend using CF generation in tests in order to verify migrations.

I write this post with a certain amount of guilt. If you look at my public coding persona (https://github.com/mikemoraned) it’s not unusual to see code with minimal tests, and a wide variety of styles and libraries. Compare that to my ‘at work’ style and, you’ll have to take my word on this, you’ll find a lot more tests and consistency. Why the difference? Most of my non-work code is the result of a Spike.

In a similar vein to my other article, it’s important to know why you are doing something, and what ‘done’ looks like.

I do a Spike for various reasons, like wanting to explore a new language, or I’ve got an idea about how something might work, but I’m not totally sure it’s feasible. A Spike could possibly go on forever, so you have to choose a semi-arbitrary limit on when to stop. If I’m on holiday then I’ve got more free time, but that also means it’s easy to get distracted into Yak Shaving territory and I also usually have a stack of ideas waiting to try out. In practice, I’m usually ‘done’ either when I’ve learned what I needed to, or a couple of days have passed.

Analogy hat on. Spikes serve the purpose that mockups do in other disciplines. It’s easy to have an idea in the shower, a lala-land where things always work, and think you are done. However, when you try to make it you find the bits are too heavy and fall apart when put together. Let’s consider a couple of recent examples.

My Playing music when someone is typing idea came when I was on a plane. After breaking it down I identified what I thought was the most difficult technical part and I did a Spike on that. I almost ran out of time, because I’d made a stupid mistake interpreting radians as degrees. However, I got to the point where I thought it was proven feasible, so I stopped and wrote it up.

Should you use tests during Spikes? Maybe. Should it be test-driven? Definitely not. If I’d done this Spike that way, then I probably would have found the radians bug, but the whole process would have taken a lot longer. Test-driven development is good for situations where you need to go from no software, to working software, delivering small units of working, valuable software along the way. With Spikes you’re taking on the risk of either delivering nothing, or, at-best, ending up with something which basically proves the point but which is very fragile. This is ok, because this is balanced against the risk of not finding out anything at all.

The reason I suspect most people who do Spikes still advocate doing them in a test-driven way is because they suspect the Spike-produced code will be taken from their hands and used for realz. You can make this less likely by using technical hints, like doing it on a branch. Ultimately, the problem of “shipping the prototype” is a social problem, not a technical one, and not one I have any easy solution to. However, for me, personally, on my own projects, I can just not be stupid.

This first example was about proving if it’s technically possible to detect fingers moving a keyboard. Any final product would look nothing like this. My second example is different, and is more akin to a working mock-up. It started out as this (excuse my ridiculously bad sketching):

As explained in the post, I have some ideas about using GeoHashes to show geocoded images. This formed in my head as way of exploring a series of pictures, and I did the sketch above around what it might look like. Over a day or so, I found a source of images, and started exploring how to show them. It was important to use real images, because I wanted to get a feel of whether exploring a real, but pseudo-geocoded, space made sense. I soon dropped a lot of what I’d originally envisaged, such as sliding your finger over images to browse them, because although it would be fun to implement, it wouldn’t help me with my larger mission. In the end, I ran out of time, but I did get as far as seeing what it felt like to explore the space, and what the problems were (“where the bits were too heavy"). I haven’t learnt as much as I’d liked but it’s important to not just blindly bludgeon your way forward, because that way leads to eventual pain.

I am currently doing test driven development for a project with Node.js. When I was testing a User 'class' that supposes to communicate with a Mongo database, I thought, what if, what if I would not choose Mongo, but another database instead, or, what if I could not get a database at the moment.

I decided to test with a mock repository instead, using some kind of dependency injection. I use Mocha as my test runner and use Chai.js for assertion.

At first, I have a user-tests.coffee that I write test cases for. My UserMemory.coffee acts as an in-memory repository that will implement register and login methods. These methods interact with an array and push or query from that array.

User = require('../libs/UserMemory').User describe "User Repo", -> userRepo = null beforeEach (done) -> userRepo = new User() done() describe "when registering a new user", -> ### test cases here ###

All the tests passed. Now I want to test User with MongoDB. I could have created the same tests and put into a user-mongo-tests.coffee with a UserMongo.coffee. But then we have duplicate codes every where. Smelly!

So, I extracted the tests into a file shared-user-tests.coffee as below:

should = require("chai").should() exports.shouldBehaveLikeAUserRepo = -> describe "when registering a new user", -> ### Test cases here ###

The user-tests.coffee now only has very little code:

UserMemory = require('../libs/UserMemory').User shared_tests = require('./shared-user-tests') describe 'User Memory Repo', -> beforeEach (done) -> @userRepo = new UserMemory() done() shared_tests.shouldBehaveLikeAUserRepo()

Note the @ in front of userRepo? This is a cool feature of Mocha that allows you to store the context in all test cases. You just have to put @ in front of userRepo in all the shared test cases.

Writing a user-mongo-tests.coffee is now pretty simple:

UserMongo = require('../libs/UserMongo').User Mongo = require("../libs/Mongo").Mongo shared_tests = require('./shared-user-tests') describe 'User Mongo Repo', -> dbInfo = name: 'test' url: 'localhost' port: 10015 mongo = new Mongo(dbInfo) before (done) -> mongo.connect => @userRepo = new UserMongo {repo: mongo} done() beforeEach (done) -> users = mongo.getCollection 'users' users.remove -> #clear the database done() shared_tests.shouldBehaveLikeAUserRepo()

libs/Mongo module is a custom written adapter to talk with MongoDB.