Today.

Matthew Mihok posted:

TDD is a weird-good practice that everyone should turn into habit

Test driven development (TDD) can be a hard switch for those of us who never were engrained with the habits early on. It feels weird...

Not that I've never seen or doubted the benefit of the practice, it just takes time to get used to. Today I'm going to document my process to where I am now. I am not an expert on the subject, but hopefully writing this down will give me some clarity.

I've heard about TDD several years ago (BDD too, but I'll get to that in another post.) It is easier to start a new project with TDD than to incorporate into something that already exists. Considering the latter, one of the questions I had in the beginning was how do you go back and test everything? Doing so could take weeks, maybe months, off of a project/product. It's not exactly easy to propose this either without having your Manager or entire sales team chasing you with pitch forks and torches. Asking around some of the best advice I have gotten regarding this issue is to start small, commit to 5% test coverage. To expert TDDr's this may seem pointless, but it's a start. Once your entire codebase(s) have 5% coverage, you can focus on 10%, and then 20%, 30 or 50%, and so on. Along with this, trying to do any new pieces to the system with 80-90% coverage is a must. Both of these tactics will help you get introduced to the idea of testing first, developing second.

Coming from a non-TDD background, test-first can be a bit of a mind-fuck. I first started off writing little bits of code, and then testing. Finally hashing out the finished function or class once I had that. This isn't necessarily incorrect, its a stepping stone to build that test-first habit. I think I'll get better at this as time goes on.

I would first start off with something like this:

DAO.create = function (conf) {
  var options = _.extend(conf, {
    host: process.env.DB_HOST || '127.0.0.1',
    user: process.env.DB_USER || 'root',
    password: process.env.DB_PASS || undefined
  });

  // Remove existing connection
  if (typeof db !== 'undefined') {
    db = undefined;
  }

  // console.log(this.options);
  db = MySQL.createConnection(options);

  return db;
};

And then write tests to check if this worked, without even running the code on its own.

Then I moved on to doing something like this:

var Node = function (options, model) {
  options = _.extend(options, {
    save: false
  });
};

// Get
Node.getById = function (id) { };

// Save (Create)
Node.prototype.save = function () { };

// Update
Node.prototype.update = function (values) { };

// Delete
Node.prototype.delete = function () { };

Where I was at least able to hash out what common functions I need, before figuring out what the hell I have to test.

Finally being able to move into actually just starting with the test file first, takes some practice, and I wouldn't suggest jumping straight into it without having some sort of transition steps first. Unless you were taught TDD when you were learning programming. Then you should be testing everything, and if you arent, shame on you! haha jk.