Skip to content

Tests

Jump to bottom
Pierre Cauchois edited this page Dec 25, 2016 · 1 revision

Tests and Code Coverage

The Azure IoT SDKs team keeps a close watch on tests and code coverage when committing new code, whether it's for bugfixes or new features:

The build is configured to fail if:

  • Any test fails
  • Code coverage goes down

We use mocha for our test framework, coupled with chai for assertions and sinon for spies and fake timers when needed. The code coverage is computed using istanbul.

3 kinds of tests can be found in the Azure IoT SDK for Node.js:

Unit tests

We use unit-tests to guarantee the behavior of a specific component and help prevent unwanted side effects induced by refactoring.

  • Each component that is defined in a lib folder of a package should have an associated set of unit tests in the test folder. This set of tests shall be named _<component>_test.js.
  • Unit tests should test only one component and not rely on external resources such as network or disk.
  • Unit tests should never block or wait and should run as fast as possible.

Integration tests

We use integration tests to quickly verify that the SDK communicates with the Azure IoT Hub service properly.

  • integration tests usually reside within the transport/protocol they are supposed to test (AMQP, HTTP, MQTT, etc)
  • The files containing integration tests shall be named _<component>_test_integration.js.
  • Those depend on external resources so special attention should be given to timeouts, and general stability.

End-to-end tests

End-to-end tests are used to validate a complete scenario from the device to the service that relies Azure IoT Hub to collect data, send commands and manage those device.

The end-to-end tests can be found in the /e2etests folder.

If you want to see how to build and run tests, you can follow the instructions in the repository

Clone this wiki locally