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