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