When we develop applications the most important thing we can do is to ship code as fast and bug-free as possible. Testing helps us achieve those goals. The number one concern for developers who do not unit test is that it takes too long. When you're first getting into utilizing unit testing in development, it may take longer than you're used to. However, the long-term benefits far outweigh that initial investment, especially if we test before we write our application code. This is known as Test-driven Development (TDD).
We need to write a JavaScript function called isPrimary.
This function's main purpose is to return true if a number is a primary number and false if it's not.
In the past, we would just dive in head-first, probably hit Google to remember what a primary number is, or find a solid algorithm for it and code away, but let's use TDD. We know our ultimate goal, i.e. to output a boolean of whether a number is a primary number or not, but there are a few other concerns we need to address to try to achieve a bug-free function:
- What parameters does the function take? What happens if they're not provided?
- What happens if a user passes in a non-number value?
- How do we handle non-integers?
When we approach a problem from a TDD perspective, our first step is to ask ourselves what could go wrong and figure out how to address it. Without this perspective, we may not think about these cases, and we might miss them. When these cases do arise, we may have to completely refactor our code to address them, potentially introducing new bugs.
One of the core tenets of TDD is writing just enough code to make a test pass. We use a process known as the red-green-refactor cycle to achieve this goal. The steps are:
- Think about the test you need to move towards completion,
- Write a test, execute it, watch it fail (red),
- Write just enough code to watch it pass (green),
- Take a moment to look at the code for any smells. If you find any, refactor the code. Run the tests with each change to the code to ensure you haven't broken anything, and
- Repeat.
Step number one is probably the hardest step for developers new to TDD and unit testing in general. Over time you'll become more and more comfortable and recognize patterns of how to test.
We've seen a couple of the advantages of unit testing already, but there are more. Here are a few examples:
- Reduces the level of bugs in code,
- Less application code because we write just enough code to achieve our goals,
- Makes it easier to refactor code,
- Provides sample code of how to use your functions,
- You get a low-level regression test suite, and
- Speeds up code-writing.
Unit testing isn't a silver bullet to writing perfect code. There are drawbacks to doing so. Here are a few of those drawbacks:
- Could give a false sense of quality,
- Can be time consuming,
- Adds complexity to codebase,
- Necessity to have mock objects and stubbed-out code, especially for things outside your control, i.e. third-party code, and
- For a large codebase, tweaking one part of your application, such as a data structure, could result in large changes to tests.
While these disadvantages exist, if we are diligent and thoughtful in our testing approach, the benefits unit of testing and TDD outweigh these risks.