When I had my first internship, I was tasked with maintaining a legacy ASP application. This included everything on the front-end, through the application layer, using Visual Basic and VBScript, as well as the database that was primarily used as a datastore for XML.
What are interns for, though, right?
I’m kidding: I actually like the idea of having junior programmers work on maintenance tasks or bugs at first to get a feel for where things are (or were) before jumping into where they are headed.
At the same time, I was also learning and reading a good bit about unit testing. It was past the time when it was “the hot new thing,” but it had hit a point where a lot of people were talking about it.
It was finding its way into day-to-day conversations. It was becoming part of the curriculum of any software engineering course or material that any software engineer should know. It was coming up in interviews, conversations, blog posts, books, and so on.
In short:
It was becoming impossible to escape.
Either you knew how to unit test, you knew TDD, or you didn’t.
- if you didn’t, then you might get an SMH from a potential employer,
- you might get a condescending comment from a peer,
- or you might get roped into a conversation covered in sheer excitement from that guy over in the cube over who’s been aiming for 100% code coverage since the company rolled out the testing infrastructure.
I’m not bashing testing (because I think it has its place and I think we need to know how to write them) and I’m not downplaying having a significant level of code coverage in a given application (because it is important).
But the amount of testing can be done is also related to a handful of others things that programmers don’t often seem to discuss: time, budget, and [optionally] pragmatism.
This post is already getting longer than what some of us like to read (are you reading this sentence, even?), so I don’t wax poetic about this for too long but if you have the time, entertain me.
If not:
The point that I’m ultimately working towards is that I don’t think it’s always as simple as basically “just write the damn unit tests.”
There are other things at work beyond just that each of which influences what we’re doing.
Continue reading
