TDD is a BIG change of mindset for development. Here's my initial thoughts after paddling around in the shallow end for a little bit.
TDD – Test Driven Development – has been on my radar for a while. This week, following conversations with friends Keiron and Joe, I decided I'd try to dig in a little bit in my "spare time" and give it a go on a micro-side-project.
I'm signed up to Adam Wathan's video course Test Driven Laravel (which, it turns out, is one of the best produced video courses I've taken – so far at least). So I'm using that to find out both Adam's way of developing with Laravel, and how to use PHPUnit (and all of Laravel's helpers) along with it.
Initial Impressions
I'd watched an intro video, and I'd seen other Laravel videos on TDD, and my initial impression has always been that this looks like a very tedious way of writing code.
The loop of run test -> determine failure -> write the next bit of code -> run test without any thinking ahead of what you might do next (e.g. I KNOW I have to create a model, migration and controller to make this test pass, so why don't I just go ahead and do all of that) has always bothered me slightly.
But I put this aside on the advice of others to try it out.
Questions as I went
I've watched 11 of the videos now – I'm just at the stage where we're simulating a real data-creation procedure.
And as I've gone through, I've been trying to apply what I've learned directly to this tiny micro-project I've started.
A few questions came up for me when I hit data creation that haven't been addressed yet, but I suspect will come up in future videos soon. But at the moment they are real questions:
- How do I test CRSF tokens?
- How do I check constraints that SHOULD be in the database (but aren't yet) such as column uniqueness?
- And, following on from question 2: if, as I'm doing the test -> write -> test loop, I have thoughts about what needs to happen in future (e.g. some column in my database will need to have unique values), where do I record those? Should I go off and write some kind of stub of a test that just passes for now?
You can see that small questions about the specifics of testing lead to bigger ones about the nature of how I should develop.
I'm SURE all this will be addressed in the course. But at the moment, I have a growing list of these kinds of issues.
Other thoughts about the TDD process
The TDD process has other things about it that need shifts inside my head.
Other things that have come up:
- How do I commit this stuff to version control in an orderly fashion? Do I commit the test and the code that makes the test pass at the same time? I wouldn't normally commit a whole set of route, controller, model and migration all at once. Is this the way now?
- It's REALLY weird being able to write code that I know works, because the tests pass, but without actually having to visit the pages you're creating. But GOOD weird!
- How do I track all the stubbed-out stuff and work that needs to be done to complete it? Adam, in the videos, is striving to get his tests to green, and he sometimes makes tests pass by creating some incomplete stub. If the development process is being driven by the tests, and the tests are all running OK, then how am I supposed to know that there is more work to do?
Summing up
I'm enjoying this process. I'm enjoying learning. And Adam's course is fantastic. And I REALLY want to get to grips with testing.
But at the moment, I feel like I've learned enough to be able to ask more and bigger questions. And I'm concerned that it will take a while to get those bigger questions answered.
Are you a developer who does TDD? What do you love about it? How did you learn? What questions – or answers – do you have?