Do you TDD?
It is my experience that most developers generally agree with Test Driven Development, but a lot have trouble actually putting it into practice. Such excuses include "but I work on a legacy app", "I don't know what I'm going to build", or "DHH said TDD is dead". I love TDD, but I have also found myself running into trouble adhering to general TDD principles and reaching for excuses.
I recently rejoined the company I work for after leaving for a year. The production database is a little over 100GB and the app is so data driven that it is just assumed that everyone has production data on their machine for development. As you could imagine, a 100GB takes a long time to download, and I just never got around to doing it. I already knew the app because I had worked on it for years before leaving. This put me in a unique place; I don't need to poke around the application in development to understand it as you would normally do when starting a new gig and setting up your machine for development.
The first ticket I worked was a fairly involved feature and I decided I would try to follow a strict TDD process. Since I didn't have a development database I couldn't make a code change and check the app quick to see if it worked. I had to write tests in order to verify the changes I was making worked. Overall I would say I had a great experience and I'd like to share what I feel worked and didn't.
Good, fast, cheap. Pick 2
One thing I've only heard a few folks mention when talking about why they don't use TDD is that it makes development take longer. I feel like many more people think this than actually say it, I myself have thought it a different points in my career. Can we write more code faster if we do not require a failing test before any code change? Sure, why not.
Let's talk about what it means to fast. If you ship a broken feature and have to fix it later, is that faster than shipping a working feature? If QA returns your ticket because it doesn't work, is that faster? Of course not. Obviously, even with TDD we can still make these same mistakes, but in my experience they are far less common. During development I was using Capybara for integration tests to test the front end logic I was adding. By nature, these tests take longer to run than unit tests because they are clicking the browser. You can save screenshots and even access console.log statements, however you still have the overhead of running the integration test each time. At some point you need to get stuff done, and this was when I strayed from my strict TDD process.
console.log driven development pic.twitter.com/N738fFgT6Z— Rob Jones (@jonesdeini) August 11, 2016