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