I like unit tests. They’re often the best documentation of a project’s behavior. They provide assurance that code modifications haven’t broken anything.
But too many or poorly-written tests can have the undesirable effect of cementing code in place, making it more difficult to change. The following are some practical things I keep in mind when writing unit tests. Read more on The Five Habits of Maintainable Unit Tests…
As the ecosystem for Elixir matures more and more, there are some libraries that seem particularly promising to me. One of them is Mox, a simple but powerful library for implementing mocks for predefined behaviours (note the British spelling!). Read more on Unit Testing Phoenix Controllers with Mox…
It’s easy to overlook the importance of unit testing. Writing tests can be tedious. They must be updated constantly as code is refactored, and when you have a large code base, you may have to write many tests to even come close to testing all cases. Despite this, unit testing is a necessary part of creating clean, working code. One way to make the testing process easier is through the use of mocks. Read more on Intro to Mocking with Moq…
Read more on Custom QUnit Assertions…
I remember one of my CS professors at Calvin starting class one day by talking about TDD (Test Driven Development). “Write your tests first, then write the code to make the tests pass,” he said.
At that point in my programming career, TDD and unit testing in general just seemed like extra boilerplate code required to make my professor happy. If my assignment didn’t have tests (or good enough tests), I got a bad grade. However, I rarely, if ever, actually followed TDD principles when I was on my own—it just didn’t make sense to me. Write the code, test it manually, and then solidify it with some automated tests—that sounded like a better use of my time. Read more on How I Learned to Love TDD…
UPDATE: Justin Searls, the author of testdouble.js sent me an email with some notes on this post. I’ve added some his comments below to provide some additional context.
Unit testing is a great way to help ensure the continuous delivery of working code over a product’s lifecycle. In client-side applications, unit testing data retrieval is especially important since using data from these asynchronous calls is at the core of what most of these apps do.
Unfortunately, asynchronous calls aren’t easy to test. Read more on Unit Testing Frontend Network Requests…
How far should we take unit testing? Should every line of code be covered by a unit test? What about code that’s hard to test? Let’s look at the cost and value of unit testing in a couple of different situations.
Tests We Can All Agree On
It’s easy to see the value of unit tests when we’re writing actual functions. Let’s say we’re writing a helper function called
next_valentines_day for our greeting card application. Here are some tests that we might write:
describe next_valentines_day do
it "returns next year's valentine's day when after Feb 14" do
it "returns same year's valentine's day when on Feb 14" do
Even from just these two tests, we we’ve significantly reduced the risk of calculating the wrong Valentine’s day in our software. And that means we’re less likely to lose valuable time fixing bugs in the code or dealing with other fallout from the code being wrong (like decreased greeting card sales). Read more on The Cost of Unit Testing…
In my last post, I argued that “untestable code” is code that cannot be efficiently unit tested. Today I’d like to walk through my top five anti-patterns that make writing unit tests painful. If you aren’t in the habit of writing unit tests, hopefully these tips will help you build more testable code and see how test-driven development can help drive clean design.
Let’s start by considering a worst-case single line method:
What’s so bad about this code? Well, let’s assume that this is a pretty important feature to get right, and that your code had better work as expected. We definitely want to be able to validate this method. Read more on This Code Is Untestable! (Part 2, for Developers)…