Posted about 3 years ago

I was having a discussion with a coworker last week about the merits of unit testing. I realized that a lot of developers may not understand them so I put this blog post together.

The Big 3 Reasons Why You Should Write Unit Tests

  • Know if your code really works
  • It will save you a lot of pain (and time)
  • It makes deployments a snap

I'd love to hear what fellow Talentopolers think and how many of them write unit tests.


You might also like

Survey Results: How Many Developers Write Unit Tests?
Why Bother With Cucumber Testing?
Unit Testing Survey - Measuring how developers use unit tests


Abelardo Gonzalez

This survey made me feel bad. I don't officially unit test. Going to have to start...

about 3 years ago   Like_icon 1 likes  
Jared Brown

Yea, I hear that a lot from developers. That is why I wanted to measure how many in fact do unit test and how much they do it.

about 3 years ago   Like_icon 1 likes  
Chris Holland

I spend a few minutes bootstrapping things such that I can test small methods as I write them, such that i don't have to execute the entire application in its whole context to see whether the code I'm writing does what I intend it to.

It speeds-up development in a big way as it saves on many clicks I would otherwise perform when doing functional testing once my code has matured and I'm hunting for bugs.

I have a Class, and methods. And I also have a Unit Test for that class which I build out incrementally. As I write a Class method, I know what its outputs should be based on various inputs, so I add a couple of tests in my unit test to verify that the Class method does what I intended it to. Click once to run the test, all green, passes. If red, then there's either something wrong with my test assertion (unlikely), or with my code (likely). Rinse, repeat.

Now, a class seldom works as an island. It relies on other classes in my system. So I'll code against interfaces of those classes, which I expect to be passed to my class, as concrete implementations of those interfaces, via the constructor or a setter method.

In my tests, I'll often "Mock Out" implementations of those Interfaces such that I can work with predictable inputs and outputs.



about 3 years ago   Like_icon 2 likes  
Lindsay Bradford

There's a key right there for me Chris. I can achieve good unit-test coverage only if I adopt dependency inversion from the get-go. It's the key to mocking up dependencies for those classes that aren't at the bottom of the call stack.

For those projects I haven't bothered with the extra effort of DI on, test coverage suffers.

I consciously don't adopt DI for my prototype projects however, because I don't want all that extra effort when I'm feeling out where I'm going.

about 3 years ago   Like_icon 2 likes  
Jared Brown

I second the concept of skipping unit tests for prototype projects. It's a PITA to go back and write unit tests for existing code, but with prototypes you don't know if they will survive as long-term projects.

about 3 years ago   Like_icon 2 likes  

Talentopoly Newsletter

A once-weekly round-up of the best programming and design posts.

Join 2050+ subscribers

We will never spam or share your email address. Easily unsubscribe

15b2f7b_speck Lindsprofileicon4_speck