Most of my day was spent on developing the User Model Layer for an application that my team and I are currently developing at DevProducts HQ. I’d like to briefly talk about how we are using TDD and discuss one major benefit that this method of development provides for my team and I during development.
While TDD has many benefits, my favourite is that it helps to keep me and the other developers on my team focussed on the components we have chosen to work on. Not only that, but it helps us focus on the task at hand as it forces us to think about each unit of the component and write it so that it _can_ be tested – as much as I’d like to expand on TDD itself, for this post, I’m just going to explain how it could help you keep focussed.
How does it keep you focussed?
Let’s take creating a user login form as an example. One of the key requirements for the application we are developing is to have a password protected administration area which requires a predefined username and password to enter. The ACL is dynamic, so an administrator has to have the ability to list, add, edit and delete users. Once the user is added, they can use the login form to identify themselves to the system with the username and password assigned to them by the administrator.
Now just as I’m typing this, a flood of components that will need to be written is coming to me - you’ll need the following:
- You’ll need, of course, the Login Form itself.
- A User Model, then the corresponding validation which will be taken care of via the form, but still you need to make sure that this ties in with everything.
- User Type and User Status Models.
- You’ll need an ACL Component.
- I like to Access to all this model functionality is simplified via a class that’s been coined as the Model Service class.
- You’ll need to Create Controller Actions.
- Along with Corresponding View Scripts.
How are you going to keep your focus with so many parts? You start from one point (the controller), make a list and start writing the application and start with “code”, “see if it works”, “next thing” kinda fashion. But what happens when you need to add something, you get called away from your desk for whatever reason (clients, ad hoc meetings etc)?
You will lose your train of thought, spend at least 20 – 30 minutes to get back to where you were and ultimately lose your focus – things are a little harder to picture. With Test Driven Development or TDD for short, we develop applications by writing the test first – the test is named as close to the business requirement as possible (such as “TestCanFindUserByUsernameAndPassword”), we write code to pass the test, then we write the next test.
I find that this keeps me focussed because when I step away from my desk or move onto other things during the day, I can come back to my unit test, and continue working from that point forward. I can focus on the task at hand since my only goal is to pass the last test I created before writing the next test. Before I know it, I’ve run out of tests to write and I’ve made several assertions on results and expectations.
Peace of Mind with TDD
There’s also the peace of mind factor – which is my second favourite benefit. You have peace of mind because you can be a little more confident that your code is working when you use TDD. This is because you have tested your code unit by unit as you wrote the application in iterations. Rather than writing the application as a whole, then testing each publicly accessible component over and over again.
Now I know that there are days when you’re just “In the Zone” and you will know where all this stuff is, what to do, how this all ties in to the point where you do a functional test and you achieve absolute perfection! But there is a reason that this is regarded as a “marveled feat” because it’s almost impossible to do and you need everything to go your way (no distractions, stars have to be aligned etc). But know this, even though you have developed the app and have tested a single method of usage, what’s to say that when it’s used in other ways it will still work?
I know this from experience and the following will happen to you:
- You will miss things.
- You go over things several times and even then still, you will miss things.
- You do lengthy functional tests over and over again because you’re paranoid (you’ve missed things before).
- You get the “that was too easy” feeling and start checking again.
- Finally, there’s the part where you think you’ve got it all submitted it to the client and then they find that you’ve missed things.
Trust me, regardless of how good a developer you are, you are susceptible to missing things. I had a junior one time who seemed to be a bright kid. Knew a lot and had the some work ethic. The developer would make up stories about friends of theirs who code in this way and write “perfect code” – I’d shrug it off and simply refute that they haven’t tested enough.
Funny enough, the more we worked together, the more I noticed that this junior worked like the fabled “perfect code” developer, but when tested enough times, bugs upon bugs upon bugs would start cropping up – thankfully this relationship is in the past which is where it will stay. There will be no way I’d be recruiting this person again. This person does not inspire confidence and really gives me no peace of mind.
If the junior dev at least knew Unit Testing, then I’d sleep easier knowing that the code they wrote is backed up by Unit Tests. I know the units of the components developed works as intended and changes can be changes can be tested easily.
Anyway, I guess this fast 15 has again gone way over time. So I’ll wrap it up here. See you on tomorrow’s fast 15.
Want to know about TDD?
I understand that this is a very general post about TDD, so if you would like to know more check out the following links:
- Test Driven Development on Wikipedia.
- Unit Testing Screencast at Zend Casts.
- The PHPUnit Unit Testing Framework
No related posts.