I find it easy to fall into the trap of wondering, how is it so many people can misunderstand testing. Sure, it’s a broad subject and there are far too many (wrong) opinions on the subject. But then, it’s easy to forget how I was also so very wrong not that many years ago. I too, thought of tests as an optional extra, afforded only to the lucky few, not those of us slogging it out in the pits of legacy code, or those of us rushing releases for a new startup.

You’ll note, I use the term us. I too have in the past, and will continue to work within complicated environments and scenarios. You do not have some special mitigating circumstance that suffices as an excuse to not follow good testing practices. Choosing to skip testing is simply unprofessional, the work of the uneducated or worse, lazy, regardless of your title or experience.

Blame

That last sentence hit you? Is it not your fault that the culture of your current company doesn’t support testing? Is it not your fault that the customers and project managers require releases faster than can be provided when including tests? Is it someone else’s fault your legacy code base doesn’t have a structure that supports component isolation? Is it someone else’s fault for writing a framework you rely on that doesn’t support dependency injection?

You are to blame.

It most definitely is your fault. Your responsibility. But regardless of situation, of excuse, the situation can be salvaged by you.

Time for change

The most common issue people raise when being introduced to testing, be that TDD (with test-first!) or comprehensive test suites, is time.

That’s not the fault of the tests. That is your fault. You have set that expectation! We have to break that cycle, and start being professional.

I can’t speak for everyone, but I know my career started in what seemed like an era absent of clean code, let alone testing. I had a great deal to learn regarding syntax, framework, domain. There were many senior to me (though no actual senior developers) with plenty of practical advice on the aforementioned subjects. Unfortunately, design patterns, SOLID, testing, and so forth, were simply not taught.

Guru

By chance, I ended up working with a guy called Phil Bennett (name and shame time, sorry Phil). I had heard whispers within the company about how excellent this guy was, though having never worked with Phil or even seen his code before, I reserved judgement.

It was mind blowing. His code was like nothing I could have imagined at the time; achieving the impossibly complex with such simple classes, such small readable methods. So many patterns throughout the code, and yet nothing seemed duplicated. His teachings came from more than 20 years experience in development. It wasn’t just tips on how to correct small portions of my own code, it was lessons in OOP. Fundamentals that had been around since the dawn of computing; terminology new to me, yet had been around long before I was born.

I was reborn anew. My guru preached the lessons of others, pushing me towards literature, books, videos. I was constantly embarrassed by how very little I had actually learned in previous years, but far more excited at just how much depth there was to go; just how radically different my approaches and techniques would be, going forward.

The point being, and I’m embarrassed to admit, it took a firm slap across my face in the shape of excellence in order for me to join Leto’s Golden Path and the see the light. Do you need a slap, too?

Material Matter

Although I can’t speak for Developers working outside of OOP, certainly those practicing C#, VB.Net, F#, and likely Java, have no excuse for not testing every line of code they write. Yes, I’m very aware how certain I/O bound operations are very difficult to Unit Test, but there’s no reason not to add Component or Integration Tests to cover I/O. Personally, I prefer emphasis towards BDD over TDD, which I’ve found binds my code to less brittle tests and makes refactoring and structural changes during early development much easier.

Moreover, there should always be at least one failing test before you write any implementation detail, and the implementation should never exceed the bounds of the test. This is where I find BDD provides much more freedom, but again that’s more personal preference.

That is the extent of the basics. That really is how simple Testing is.

Resources

There is such a wealth of resources out there, at your finger tips. Uncle Bob has some excellent videos (part 1 & part 2) if you have the money to get you started, but ultimately you’ll want to look at frameworks related to your languages. Whether that be ASP.Net MVC or best practices for Java.

Most companies I’ve worked for will put up part, if not all of the cost for learning materials, so why not talk to your manager about purchasing a book or two or a pluralsight subscription. If you can’t find the funds, just google it and check out some other articles out there. Martin Fowler recommends James Shore’s article and screencasts, whilst Uncle Bob has a variety of links, articles, and books.

When I work with a new Junior Developer, I teach them TDD on their first day. It takes less than one day for a Junior, not necessarily as well versed as you in syntax and frameworks, to learn TDD. How long will it take you?