I have an ongoing interest in various development methodologies, even though I’ve never worked anywhere where we applied any sort of formal approach to software development. Extreme Programming has gotten a lot of attention for the past few years, but I’ve never really wanted to work in that sort of environment, in large part due to pair programming. I’ve read any number of testimonials that describe hwo much more productive pair programming can make you, but for me getting to work on my own without someone sitting next to me all day is a quality of life issue. I think I’d get burned out if I couldn’t click over and read a news article or my personal email every now and then, and I’m pretty pleased with my produtivity working solo anyway.
One of the pillars of XP that has really caught on, though, is the test first approach. In other words before you write code that, say, fetches a record from the database, you write a unit test that will exercise the record fetching code. Then, when you write the record fetching code, all you have to do to make sure you’ve done it correctly is run your unit test. Even better, as you add more and more things to the system, you can always go back and run that unit test and make sure that your record fetching code still works as intended. Nearly any software engineer sees the value in writing unit tests, and writing them first is no doubt the best time to do it, because then they’re done and you don’t have to think about it. If you write features before the tests, there’s a great chance you’ll never get around to writing the tests at all, because it will be time to move on to the next feature.
Test Driven Development seems to me to be an outgrowth of XP that focuses on the test-first approach without a lot of the other XP baggage that people find off putting, and indeed it intrigues me greatly. I see the value in writing my software in a test-first fashion. I intend to do it, and yet I’ve never gotten into the habit, for several reasons.
The first is that JUnit (a popular unit testing framework for Java) is not second nature to me yet. I’ve written tests with JUnit, but not enough that I can write them without thinking about how JUnit works. That just takes time, but until it’s second nature, writing tests will feel like a chore. I just need to do my chores. The second is that even though Martin Fowler will tell you that the test first approach is faster, it doesn’t intuitively feel faster. That combined with the JUnit overhead adds up to a big deterrent. And the final reason is that I don’t have a good mental model for where to put the test classes in relation to the actual classes that are part of the system, how to integrate the tests into the build process, and what the scope of each test should be. Then there’s the matter of dealing with the data created during the testing process.
Let me go into the last point a bit more. Let’s say you’re writing a test for a class that inserts records into a table. That table does not allow you to insert duplicate records. How then do you write a unit test that you can run repeatedly? One option is to fetch the most recent record (perhaps as part of another unit test), and then somehow increment the information in it to make sure you’re generating a unique record. I’m certain there are common practices here, but I don’t know what they are.
One thing I know for certain is that developers with blogs tend to be way ahead of the curve when it comes to software engineering practices. I’m almost ashamed that I don’t write my code test first, due to fear of mockery by Javabloggers who do things that way. There’s a Martin Fowler interview on test driven development that’s helpful, but I’m still looking to learn more. Kent Beck has published Test Driven Development: By Example, but I haven’t picked it up, and I’m hoping not to have to. I’m trying to avoid buying computer books these days for some reason. Anyway, expect more posts on test driven development, because I’m determined to apply it in my everyday work.
Test Driven Development
I have an ongoing interest in various development methodologies, even though I’ve never worked anywhere where we applied any sort of formal approach to software development. Extreme Programming has gotten a lot of attention for the past few years, but I’ve never really wanted to work in that sort of environment, in large part due to pair programming. I’ve read any number of testimonials that describe hwo much more productive pair programming can make you, but for me getting to work on my own without someone sitting next to me all day is a quality of life issue. I think I’d get burned out if I couldn’t click over and read a news article or my personal email every now and then, and I’m pretty pleased with my produtivity working solo anyway.
One of the pillars of XP that has really caught on, though, is the test first approach. In other words before you write code that, say, fetches a record from the database, you write a unit test that will exercise the record fetching code. Then, when you write the record fetching code, all you have to do to make sure you’ve done it correctly is run your unit test. Even better, as you add more and more things to the system, you can always go back and run that unit test and make sure that your record fetching code still works as intended. Nearly any software engineer sees the value in writing unit tests, and writing them first is no doubt the best time to do it, because then they’re done and you don’t have to think about it. If you write features before the tests, there’s a great chance you’ll never get around to writing the tests at all, because it will be time to move on to the next feature.
Test Driven Development seems to me to be an outgrowth of XP that focuses on the test-first approach without a lot of the other XP baggage that people find off putting, and indeed it intrigues me greatly. I see the value in writing my software in a test-first fashion. I intend to do it, and yet I’ve never gotten into the habit, for several reasons.
The first is that JUnit (a popular unit testing framework for Java) is not second nature to me yet. I’ve written tests with JUnit, but not enough that I can write them without thinking about how JUnit works. That just takes time, but until it’s second nature, writing tests will feel like a chore. I just need to do my chores. The second is that even though Martin Fowler will tell you that the test first approach is faster, it doesn’t intuitively feel faster. That combined with the JUnit overhead adds up to a big deterrent. And the final reason is that I don’t have a good mental model for where to put the test classes in relation to the actual classes that are part of the system, how to integrate the tests into the build process, and what the scope of each test should be. Then there’s the matter of dealing with the data created during the testing process.
Let me go into the last point a bit more. Let’s say you’re writing a test for a class that inserts records into a table. That table does not allow you to insert duplicate records. How then do you write a unit test that you can run repeatedly? One option is to fetch the most recent record (perhaps as part of another unit test), and then somehow increment the information in it to make sure you’re generating a unique record. I’m certain there are common practices here, but I don’t know what they are.
One thing I know for certain is that developers with blogs tend to be way ahead of the curve when it comes to software engineering practices. I’m almost ashamed that I don’t write my code test first, due to fear of mockery by Javabloggers who do things that way. There’s a Martin Fowler interview on test driven development that’s helpful, but I’m still looking to learn more. Kent Beck has published Test Driven Development: By Example, but I haven’t picked it up, and I’m hoping not to have to. I’m trying to avoid buying computer books these days for some reason. Anyway, expect more posts on test driven development, because I’m determined to apply it in my everyday work.
Commentary
Previous post
The cards are on the tableNext post
The missing link