unit testing

Getting Started Unit Testing with Kotlin

I’ve recently been playing around with Kotlin in my free time, particularly as an alternative to Java for Android development. Figuring out where to start exploring a new language can be difficult, but knowing that Atomic Object practices test-driven development (TDD), I figured that learning to test in Kotlin would be the best option. Read more on Getting Started Unit Testing with Kotlin…

The Five Habits of Maintainable Unit Tests

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…

Mocking in JavaScript Unit Tests Using Sinon.JS

Lately, I’ve been using Sinon.JS for mocking in my unit tests. By using mocks for dependencies inside functions, I can write unit tests that are resilient to a changing codebase. Functions with mocks can also be developed without worrying about the chain of dependencies that could affect the logic inside the functions. Read more on Mocking in JavaScript Unit Tests Using Sinon.JS…

Intro to Mocking with Moq

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…

How I Learned to Love TDD

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…

Bye-Bye, Sinon – Hello, testdouble

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.

I’ve been working in JavaScript-land for the last little while, writing lots of Node.js code. Since I practice TDD, I’m always trying to keep my eye on the best new ways to test JavaScript code. Read more on Bye-Bye, Sinon – Hello, testdouble…

Unit Testing Frontend Network Requests

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…

The Cost of Unit Testing

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
    expect(next_valentines_day('2014-02-15')).to eq('2015-02-14')
  end
  it "returns same year's valentine's day when on Feb 14" do
    expect(next_valentines_day('2014-02-14')).to eq('2014-02-14')
  end
end

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…