First, I suppose I should apologize for two days of silence. I am currently going through a major life transition, so things could get a little spotty for a while. I haven’t forgotten about you. I actually have had a couple of days where my experiment for the Gist of the Day failed, and I couldn’t get something working in time to put it up.
Today, however, I do have something for you!
Today we are going to cover two topics very briefly (as usual): 1) how do you factor files you wrote into your tests, and 2) how do you write your code with testing in mind (which you should).
The Scenario
This is story is actually a true even which did take place. I am not mentioning names, but if I were to mention names I would change them to protect the innocent.
So I have a client who is having trouble with a project I did for him. He’s seeing that the authentication which he asked for which is tied to the IP address isn’t working. Now, he’s in a shared hosting environment which uses a lot of virtualization, so I suspect that there may be some problem with his host. I cannot go and tell him that without data to back me up, because I could be wrong; it could totally be something wrong with my code. So that means I need more information.
How do you get more information? Well, the simplest way is to print stuff to the web server logs and look there, but this shared hosting environment puts all of their clients on the same error log. This means that there are dozens of writes to this error log per second, which means finding my print is going to be tricky, especially since the only way to see the log is using their very limited web page which only shows 100 lines on the screen at a time. So this means that I need to generate my own log file.
One of the things I’m really proud of with this project that I did is that I have very high test coverage. I’m approaching 93% test coverage (it’s a small project, so it isn’t that impressive). So when writing my log I want to have adequate tests so I can maintain this. This means two things: 1) it means I need to design my code to be tested, and 2) it means my tests are going to need to verify the lines written to disk.
The Code
The Conclusion
Automated testing is super important, and I think that it is a wonderful trend that we’re seeing more and more people consider this not just a best practice, but that consider it a necessary part of what it means to be a developer. The old stand-by’s of “it’s too big,” or “it takes too much time” are falling by the way-side, and people are starting to do much more test-driven development. The basic truth is that even low test coverage is better than no test coverage, and it really doesn’t take that much time to start adding tests to your code one piece at a time.
That said, if you’re writing a new application, it does really help to have your tests in mind when you lay code. It is crucial that people know how to construct test plans, know what fixture data and mocking are and know how to do it, and know how to apply basic testing methodology to their software.
When I was younger I remember having a very wise and experienced senior colleague tell me that if you don’t have a test to prove that it works, it doesn’t work. I think that is a wonderful guideline for how to do software.