Freigeben über

JavaScript unit testing: guiding principles and common excuses

  • Artikel

There's a lot of interest in JavaScript at Microsoft. Did you know that:

  • JavaScript is one of the officially supported languages for Windows 8 and Windows Phone development
  • Azure Mobile Services, a mobile backend-as-a-service, is written in Node.js
  • Apps for Office are written in JavaScript

 

As a consequence, Visual Studio is an excellent tool for writing JavaScript, even if you're just writing a web app and not a Windows app. In my opinion, if you want to write reliable code in a dynamically typed language such as JavaScript, you really need to write unit tests. Part one of this blog series will offer some guiding principles for writing unit tests, and common excuses people give when they don't. In part two, we'll write a JavaScript unit test using Mocha. In part three, we'll use a Visual Studio extension called Chutzpah to run your tests.

What are unit tests?

Let's make sure we're all on the same page. A unit is a small section of code. Unit testing means you test that bit of code to make sure it functions properly. This increases confidence in your code.

Unit tests are important when many people work on the same codebase. If one engineer changes code in one part of the project, you want to ensure that the rest of the project still works.

Unit tests are especially important in dynamically typed languages such as JavaScript, since there is no compiler to catch common problems.

Guiding principles for unit tests

  1. Predictable. If you have a certain input, you should always get the same output. Your input should always be static. For example, don't pass a random number or the current time as an input.
  2. Pass or fail. It should be obvious if your test passed or failed.
  3. Self documenting. Your code should describe what the test is meant to do. Another engineer looking at your test should immediately be able to understand it. It helps if you use testing and assertion frameworks which read like English.
  4. Single responsibility. Unit tests should only test one single thing at a time. If you want to test more things, then write more unit tests.
  5. Useful error messages. When a unit test fails, the error message should be useful.
  6. Not integration tests. Unit tests don't test multiple components. Unit tests come first, then integration tests, then validation tests.

Common Excuses

  1. Too busy. "I have too many other things to do." "There's plenty of time after development to catch bugs." When you fix a bug and it breaks something else, it's called a regression. Unit tests can prevent regressions.
  2. Too hard. "It's too difficult to write unit tests." "It'll take too long because I'm not experienced."
  3. Too confident. "I don't need unit tests. My code works." "Why waste time writing unit tests because my code works?"
  4. Too lazy. "There are other things I'd rather be doing." "I just don't want to write unit tests."
  5. Too cumbersome. "It takes too long to run the unit tests." "I keep forgetting to run the unit tests."

 

If you find yourself making one of the excuses above, do yourself a favor and work to get over it. Like anything, there's a bit of a learning curve. However, you'll save yourself countless frustrating hours down the road if you put in a little time now to learn this. It's not as burdensome as you might think.

In the next post in this series, we'll start writing JavaScript unit tests with Mocha.

Acknowledgments: This blog series is based on this excellent course on Pluralsight: Front-end First: Testing and Prototyping JavaScript Apps by Elijah Manor. Content reproduced with Pluralsight's permission.