Here comes the day I had been waiting for since the very first day i started my internship…I made my first svn commit today. svn stands for SubVersion. Its a studd way of keeping ur code under strict version control. We write code and we write a lot of that. Many a times we need to revert back to the old code when things don’t work as expected. This version control system comes handy in such situations. All you need to do is shoot a command on the terminal and you’ll have the old code base back on your system. I worked on my first story, it was a short one, in fact a zero pointer, and had to do with the view of the form of the app we’re working on. The feeling that you have when you make the transition from a learner to a developer is just great, it can’t be expressed, you need to experience it to know it. Its like coming out of the egg shell, facing the world. It takes away all the securities that you have. But then it also brings with itself a lot of responsibilities.
I’ve been interning at a custom software development company since the last one month. We use Test driven development for developing the software. My experience and opinion…? its funny…
I had never indulged in TDD before, so during my 1st week, I was completely amazed as to what’s happening. We would go through the customer stories, and pick up one based on the customer’s priorities. Then think for a while what it means, and without wasting any more time, announce it loud to out other team members sitting on the adjacent table that we’ve picked up this xyz story and are goin to ork on the same.
Then start writing a test, yes go for the test straightway… even before writing your code. Once you’ve written the test, run the test and watch it fail. The test lists down all the failures. Now wihout using too much of your brain, go and start handling the filures, one at a time. Write a code that just handles the failure you’re working on. Need not to be foresighted. Just write a code that passes through the test that failed. When you’re done with it, njoy, because this is PROGRESS. In this manner, go on and code to pass all the failed tests.
It sounds strange, I know. In fact when I first came across this practice, I thought we’re unnecessarily wasting a lot of customer money. But days passed by and i after a month, I have my own fundas as to how this whole concept of test driven development makes a lot of sense. I’ll give an one of several example of how this concept of TDD impressed me.
During the week 2 I was pairing with Ry… and we were working on email notifications. The story says that at the end of every week, the app must send a email notifying all the users about the events that match their interest. ok fine, we wrote the tests and then wrote the code. It worked and at the end of the week, the beta customers received the emails about the events they were interestd in. Good.
Then came the week 2 and time for partner swapping. Now I was working with Jus… on the message notification story. It says, whenever a user writes a message to another user, the recipient must receive n email, notifying him about the message. We started by writing the test and then the corresponding code. The tests passed, the mails were sent and we were happy.
Then we ran all the tests that we hd written till date for the app, and went off to have some snacks(It takes a lot of time to run all the tests..and its not all that interesting to watch all those green dots apppearing on the terminal. When we came back, we found that we had some broken tests. We ran through the tests report and found that the test for weekly email notification was broken( yes, the same Ry… and I had written last week. Bizarre, how could we break a test which we never touched. Hadn’t it been the test report, we would have never thought of going through the weekly email notification stuff. It hardly had anything to do with the messages. It was a cronjob and completely out of our context. The test report told us exctly what was broken. We went to the test and found that we were using the same notification templete for sending the mails that weekly notification was using. And we had made some changes to the code to do what our message notifier wanted to do. We went back to our message notification code and fixed it.
Had it not been the tests, we would have never been able to identify the problem. The tests that i had written a week back helped me to discover a bug. You write a test once and then it helps you throughout your project. I wish people were as faithful a the tests. When your project strts gaining weight and you accumulate tons of code, it is these tests that help you ensure that you don’t break anything old, while writing something new. This way you can focus on writing new code, without worrying about the old code.
And trut me its fun writing the test, and when you see the tests pass, you feel happy, and when the tests fail, they shout it loud why they failed. so you know why they failed, and you know what to do to make them pass…! Life couldn’t be easier…!