js.component

MochaTestClass (Interface)

About

js.component provides an implementation of the mochaopen in new window test framework, but it is up to you to actually write the tests. In the js.component test framework, tests are written using classes. This is the interface for your test classes, which are responsible for doing two things:

  • Defining what tests to run
  • Implementing the tests

Why test?

Every method and function in an application has an implicit contract with its caller: given certain inputs, it will produce certain outputs. When that contract is broken, you’ve got a bug.

How to ensure a method/function is fulfilling its contract? You can test it manually, but it’s difficult to keep track of all of the possible inputs and outputs. And more importantly, when a method/function is modified at some later date, a subtle bug may be introduced that breaks the contract.

This is why automated testing is so important. You can quickly test the assumptions you have made about how a method/function operates in a reproducible fashion, and view the results all at once. And when you make changes to your application, you can run the tests again to ensure you haven’t broken anything.

Of course, no test suite is infallible; there will always be conditions you will miss that will trigger a bug. But it can catch a lot of bugs that would otherwise slip through.

Writing tests

Here are the recommended steps in writing a test suite for a method/function:

  • Decide exactly what it is supposed to do.

  • Document what it outputs, both in terms of returned values and work done, it will do given each possible set of inputs.

  • Write a test for each possible set of inputs to confirm your assumptions.

  • Be sure to include unexpected values in your tests: empty strings/collections, null or undefined values, negative or out of range numbers, etc. These edge cases are often the source of bugs.

  • Run the tests and fix any bugs that are uncovered.

In the process of writing tests, you will often find that your assumptions about how a method/function operates are incorrect. This is a good thing! It means you are learning more about the method/function, and you can update your documentation and tests to reflect the new understanding. Or you may decide that the API of the method/function is not as clear as it could be, and you can refactor it to make it more intuitive.

Structuring your tests

When you have a large number of tests, it usually makes sense to structure them hierarchically into test suites. A test suite — which is implemented by the MochaSuite class — may contain zero or more tests, and zero or more child suites. This structure conveys several advantages:

  • It potentially makes test output much easier to read, as you can display the hierarchy visually. This is what the default html reporter does.

  • It allows you to easily disable a group of tests by disabling a single suite.

Test functions

Your test class must implement one or more test functions, each of which must have a name that begins with "test". Typically you will have one test function for each global method and class function in your application. Of course, a test function can also be more abstract, testing a group of related methods/functions.

See .testSomething() for more information on how to write a test function.

API

constructor()

constructor(suite : cs.js.MochaSuite)

You are not required to provide a constructor for your test class. There are two reasons you might want to do so:

  • You want to provide a custom name for the test suite. In that case, set This.name to the desired name.

  • You want to temporarily disable the test suite. In that case, call $suite.only().

Examples

Let’s say you have a class called MyClass that you want to test, and in the report you want it to have the title "My totally awesome class". You might write a test class like this:

class constructor($suite: cs.js.MochaSuite)
  $suite.name:="My totally awesome class"
  
Function testSomething($suite: cs.js.MochaSuite)
  // ...
  
Function testSomethingElse($suite: cs.js.MochaSuite)
  // ...

Now let’s say you want to temporarily disable the class’ test suite, because you are working on a new feature and you don’t want to be distracted by the test failures. Easy:

class constructor($suite: cs.js.MochaSuite)
  $suite.name:="My totally awesome class"
  $suite.skip()

Now let’s say you are fairly confident that the tests in the class will work and you want to focus only on that class’ test suite, and ignore all other test suites. Also easy:

class constructor($suite: cs.js.MochaSuite)
  $suite.name:="My totally awesome class"
  $suite.only()

.testSomething()

.testSomething(suite : cs.js.MochaSuite)

This is the signature for a test function, where "Something" is typically the name of a method or function that you want to test. In order to be recognized as a test function, it must have a name that begins with "test". Test functions take a single argument, which is the class’ test suite.

Within the test function, you will usually call $suite.describe() to create a child suite under which the tests will be grouped.

Then you will typically use .specify() or .should() to create a test for each possible set of inputs to the method/function you are testing.

See MochaSuite for examples.

Last Updated:
Contributors: Aparajita