1# phosphor-power-sequencer testing
2
3## Overview
4
5The [test](../test) directory contains automated test cases written using the
6[GoogleTest](https://github.com/google/googletest) framework. These tests are
7run during Continuous Integration (CI) testing.
8
9The goal is to write automated test cases for as much application code as
10possible.
11
12## Test case conventions
13
14Each implementation source file should have a corresponding tests file. For
15example, [rail.cpp](../src/rail.cpp) is tested by
16[rail_tests.cpp](../test/rail_tests.cpp).
17
18Within the tests file, there should be a TEST for each public method or global
19scope function. For example, `Rail::isPresent()` is tested by
20`TEST(RailTests, IsPresent)`.
21
22## Mock framework
23
24One of the primary challenges with automated testing is handling external
25interfaces. The phosphor-power-sequencer application depends on the following
26external interfaces:
27
28- D-Bus
29- Journal
30- Error logging
31- GPIOs
32- sysfs files containing PMBus information
33- BMC dump
34
35These interfaces are either not available or do not behave properly within the
36CI test environment. Thus, in automated test cases they need to be mocked.
37
38The GoogleTest mock framework is used to implement mocking. This allows the
39behavior of the external interface to be simulated and controlled within the
40test case.
41
42The mock framework typically relies on a class hierarchy of the following form:
43
44- Abstract base class with virtual methods for external interfaces
45  - Concrete sub-class with real implementation of virtual methods that call
46    actual external interfaces
47  - Mock sub-class that provides mock implementation of virtual methods
48
49The phosphor-power-sequencer application follows this pattern using the
50following classes:
51
52- [Services](../src/services.hpp)
53  - [BMCServices](../src/services.hpp)
54  - [MockServices](../test/mock_services.hpp)
55