As I’ve gone farther down the road I’ve learned the value of testing. My first introduction to unit testing was through JUnit in a Java project I worked on last year. Now, there has been a recent push for testing in PHP web apps that used to be homegrown in the worst ways and need to extend past the typical “what, it works, shutup” approach to PHP testing.
Not testing is not healthy. Sooner or later you’ll be wrong, which will make you a huge jackass. And nobody likes being that guy. I know I have been on occasion. It sucks, and it can make people second guess you, which sucks even more down the road.
So cover your ass by making a paradigm shift when it comes to your development habits and approach:
- Create tests that you know would work if you wrote your scripts right — as best you can, don’t go for 100% coverage, just get something up there to mimic the typical “yeah okay it works at least, but not quite” once-overs you do
- Assume what you’ve written is wrong
- Run your tests, and see if they work
I’ve been convinced that this approach to programming is much healthier (thanks Shaver) because it forces people to think before writing the bulk of their code — possibly alleviating problems before they happen. Duh, right? Everybody knows that, right? Well, not everybody does it, and there’s a big difference.
I think that ideally, everybody would create tests for just about everything possible, but I do have some reservations when it comes to that.
For one, sometimes you just don’t have time. This is a terrible excuse, and I guess it depends somewhat on the scope and sensitivity of your project. But, if your project is planned right you should have the time and resources to get in a fair amount of code coverage without jeopardizing your timeline. And, arguably, if you’re already used to a test-oriented approach to development things might actually be faster.
Another thing I’ve tried to identify is when I’m overdoing it (this is more of a fear). So, okay, you want to test your code as much as you can, but there’s a line I wouldn’t want to cross. It’s the line between having a complete and working end product and having an incomplete product with complete and exhaustive tests. In that case, I’d vote to let some of the testing slide, but not all the way, in favor of a more complete product.
The long tail of development can pick up the slack for more exhaustive tests and bug fixes that you ideally would only fix once — write a test for the bug, fix the bug, done. Most of it would probably be doable during alpha or beta releases — it’s what they are for. I’d argue that it’s also more productive during that time because you might have a better knowledge of your app and be in a better position to spot unforeseen problems and write proper tests.
I’ll be honest; for me it’s been a bit of a learning experience. A welcome one, for sure, but frustrating at times because you’re always going to run into “oh shit, my bad” situations when you’re trying to change mindsets and unlearn bad habits. In PHP, I think this is probably a bigger issue than in other languages because it already lacks a bit of structure by nature. There’s also the programmer laziness hurdle to overcome. It’s a big one.
There are some decent PHP testing tools out there that sometimes gather dust — especially in PHP. But, if PHP is going to break more into enterprise development, I think they will gain in popularity. Here are some PHP testing links for you:
- Simple Test
- Apache::Test – also see Chris Shiflett’s blog and his presentation on PHP testing
So — PHP developers, it’s time to stop being lazy and take a serious look at this stuff. If you get an irritated feeling because I said that, it’s because you’re wrong and you’ve just gotten used to being wrong.
Comfortable and easy doesn’t get you anywhere in the long run.
8 thoughts on “Testing Habits Are Your Friend”
Please do not link to a project that has been dead for years. The “real” PHPUnit can be found at http://www.phpunit.de/.
Right — sorry, wrong one. I’ve updated the post. Thanks for the heads-up. 🙂
Thought I’d mention that Chapter 8 of the PHPUnit guide is pretty much what I’m trying to say, only not as well.
Mike, well written. Which of these testing suites will you use? Or are you giving us the choice because you are still indecisive yourself?
I agree with you wholeheartedly, though it applies to developers in all languages. In 2001 I came up with the following saying:
“The first step in confirming there is a bug in someone else’s work is confirming there are no bugs in your own.”
Sometimes the right testing suite depends on what framework you’re using — but overall they are similar enough. PHPUnit is pretty awesome, and I like it’s documentation a lot. But Simple Test is what we’ve been using recently because it fits in with CakePHP. I liked Shiflett’s presentation but haven’t done a whole lot with the test-more.php class.
Thinking before writing code? That’s the paradigm shift right there ;P
What about functional testing in conjunction with unit testing? Where I work we’ve been using funkload (a Python library for automated functional testing and load testing) and AutoIT (a Windows-only scripting engine for keyboard and mouse input) for functional testing.
I completely agree that not testing boils down to laziness. I’ve been unittesting my php/js code for a few years now and wouldn’t turn back. I have to deploy several frameworks I’ve written. When I make major changes, it’s sure nice to see that pretty little green bar 🙂
I don’t want those “hey something is broke” emails, and haven’t had one in a long while.
Comments are closed.