Yesterday, I talked about my evolving thinking about JavaScript testing. One of the things that often gets missed in articles about the kinds of tests you can write is how to actually write them.
Today, let's talk about that!
Assertions
Testing libraries use assertions to run there tests.
Assertions are functions, usually in plain language, that describe what you're trying to test, and what the expected outcome or result should be.
Using Chai, an assertion library, as an example, here I'm stating that I expect()
the output of adding 4
, 6
, and 8
to.equal()
the number 18
.
expect(add(4, 6, 8)).to.equal(18);
If that is the output of the add()
function, a value of true
is returned and the test will pass. If not, false
is and the test will fail.
Running tests with Mocha
Chai doesn't run on its own. It gets paired with Mocha, a testing framework that runs the actual test.
(If you missed it, I wrote about how to run JS tests in the browser with no build step last Friday.)
Inside your testing file, you first destructure the expect()
method from the chai
library…
Then, you use Mocha's it()
method to describe what you're actually testing…
const {expect} = chai; it('add() should add two or more numbers together');
The it()
method also receives a second argument: a callback function that runs the actual assertion test or tests…
const {expect} = chai; it('add() should add two or more numbers together', function () { expect(add(4, 6, 8)).to.equal(18); });
Generally speaking, each it()
method should run one assertion test, but there may be situations where two related assertions that test the same thing get run together.
An example
I have an add()
method as part of a calculator.js
library.
If the user passes numbers in, it should return the sum of those numbers. If the pass in just one number, it should return that number back out. If they pass in no numbers, it should return 0
.
// Should returns 42 add(40, 2); // Should return 3 add(3); // Should return 0 add();
Here's what the function itself it looks like.
The ...nums
variable is a rest parameter that returns an array of all the arguments passed into the add()
function.
I start with a total
of 0
, then loop through each num
in the nums
array and add it to the total
. Then, I return
the result.
/** * Add two or more numbers together * @param {...Numbers} nums The numbers to add together * @return Number The total */ function add (...nums) { let total = 0; for (let num of nums) { total = total + num; } return total; }
We have some defined expectations or requirements about how the function should run and what it should return
in different situations.
Let's write some tests to ensure that's how our function behaves.
Writing our unit tests
Inside my test.calculator.js
script, I destructure the expect()
method from chai
.
Then, I define the three things I want to test using the it()
method. It should:
- Add two or more numbers together.
- Return the original value if there's only one number.
- Return
0
if no numbers are provided.
const {expect} = chai; it('add() should add two or more numbers together', function () {}); it('add() should return the original value when one number is provided', function () {}); it('add() should return 0 if no numbers are provided', function () {});
Then, I can write assertions to test each of those expectations.
const {expect} = chai; it('add() should add two or more numbers together', function () { expect(add(4, 6, 8)).to.equal(18); }); it('add() should return the original value when one number is provided', function () { expect(add(42)).to.equal(42); }); it('add() should return 0 if no numbers are provided', function () { expect(add()).to.equal(0); });
When I run my test, those tests should pass. If they don't, there's an error in my code that needs to be fixed.
What next?
Tomorrow, we'll look at how to organize your tests as your test suite grows.
On Thursday, we'll look at TDD and how we can use it write better code, faster. And on Friday, we'll talk about code coverage, implementation details, and why neither of them really matter.
Cheers,
Chris
Want to share this with others or read it later? View it in a browser.
0 Komentar untuk "[Go Make Things] How to actually write unit tests"