One of my favorite current shows is The Newsroom.[ref]Yes, I realize it's about to begin it's third and final season. I'm not upset it's being cancelled, I'm excited a third season is happening at all.[/ref] If you haven't watched it, it's an Aaron Sorkin drama that takes a heavily fictionalized view of what happens behind the scenes of a nightly news show.
What's more, the episodes frequently parallel current events, making Sorkin's not-at-all-veiled social commentary even more striking. One episode even takes a look at the attempted assassination of Rep. Gabby Giffords and the utterly botched news coverage of the event.
Essentially the fact that, for ratings, every network was quick to jump on the bandwagon of reporting her death, even though their evidence was spotty and, in fact, she survived. The best line from the episode:
It’s a person. A doctor pronounces her dead, not the news.[ref]‘The Newsroom’ Season 1, Episode 4, ‘I’ll Try to Fix You’: TV Recap[/ref]
So often we're in such a hurry to be the one breaking a news story that we forget to fact check or look outside our protected little bubbles for validation before making a statement. I've done it, you've done it, we've all done it. We've all made a grandiose, authoritative statement that ultimately proved to be false.
I've been working professionally as a developer for 7 years.[ref]I'm not counting the time I spent learning to freelance before I started taking full-time gigs. Yes, I was a professional, but my focus was elsewhere.[/ref] I've been writing OOP-style code for just about 6 years. I've only been using version control systems for 5 years.
And I've been writing unit tests for my code for 4 years.
While the concept of unit testing is very well-established in the history of development, the practice is relatively young in many communities. Only 20% of the .Net developers I worked with knew how to write a unit test. Even fewer of the PHP developers I work with test their code.
Still, there is a very live interest in testing among all of these communities. Every single conference session I've proposed about unit testing has been accepted - and the rooms have been packed.
One of the most discussed topics around unit testing is that of TDD - the idea that you write your tests first and then write code that passes those tests. It's one of the more popular ways to work on unit tests, not because it's easy, but because it ensures your code is actually tested before you ship.[ref]If you don't mandate tests first, I guarantee you will ship untested code. Once you skip the test suite, it's very hard to justify time/salary/budget/resources to come back and write tests later.[/ref]
It's also incredibly hard to do. So hard in fact, that developers who don't understand unit testing are quick to write TDD off as either antiquated or irrelevant.
Some even go so far as to declare it "dead."
To borrow from The Newsroom, a development community declares a practice dead, not a self-centered blogger.
I will readily admit that I don't always test my code. Sometimes, I even write the code first and come back to write a test afterwards once I've decided on the architecture. I'm not going to go on a rampage saying all testing must be done first.
But I will point out the immense value in such a pattern.
Firstly, it forces you to build objects and functions in an extensible, documented manner. Functions that do something but return nothing are inherently difficult to test. Objects that talk directly to the database (or an API) without routing through a mockable service object are inherently unscalable - you can't replace the database/API with a different implementation.
Blindly declaring TDD - a practice only just beginning to take off in many communities - dead signals a deep failure to understand the point of writing code tests-first in the first place. It reeks of naïveté at best, and points out deep-seated hubris at worst.
Testing, and test-driven development, is alive and well. Ignore it at your own peril and the risk of becoming obsolete as the world moves on.