Testing

doc
1

Charms should have tests to verify that they are functioning correctly. This document describes some of the various types of testing you may want to consider – their meaning, recommended coverage, and recommended tooling in the context of a charm.

Contents:

Unit testing

See also: How to write a unit test for a charm with Harness, How to write a unit test for a charm with Scenario

A unit test is a test that targets an individual unit of code (function, method, class, etc.) independently.

Unit tests are intended to be isolating and fast to complete. These are the tests you would run every time before committing code changes.

Coverage. Unit testing a charm should cover:

  • how relation data is modified as a result of an event
  • what pebble services are running as a result of an event
  • which configuration files are written and their contents, as a result of an event

Tools. Unit testing a charm can be done using:

Examples.

Integration testing

See also: How to write integration tests for a charm

An integration test is a test that targets multiple software components in interaction. In the context of a charm, it checks that the charm operates as expected when Juju-deployed by a user.

Integration tests should be focused on a single charm. Sometimes an integration test requires multiple charms to be deployed for adequate testing, but ideally integration tests should not become end-to-end tests.

Integration tests typically take significantly longer to run than unit tests.

Coverage.

  • Charm actions
  • Charm integrations
  • Charm configurations
  • That the workload is up and running, and responsive
  • Upgrade sequence
    • Regression test: upgrade stable/candidate/beta/edge from charmhub with the locally-built charm.

When writing an integration test, it is not sufficient to simply check that Juju reports that running the action was successful; rather, additional checks need to be executed to ensure that whatever the action was intended to achieve worked.

Tools.

Examples.

2