1# 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::configure()` is tested by 20`TEST(RailTests, Configure)`. 21 22## Mock framework 23 24One of the primary challenges with automated testing is handling external 25interfaces. The `phosphor-regulators` application depends on the following 26external interfaces: 27 28- D-Bus 29- Error logging 30- Hardware presence 31- Hardware Vital Product Data (VPD) 32- Journal 33- Sensors 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 49`phosphor-regulators` follows this pattern using the following classes: 50 51- [Services](../src/services.hpp) 52 - [BMCServices](../src/services.hpp) 53 - [MockServices](../test/mock_services.hpp) 54