1*80689db1SShawn McCarney# Testing 2*80689db1SShawn McCarney 3*80689db1SShawn McCarney## Overview 4*80689db1SShawn McCarney 5*80689db1SShawn McCarneyThe [test](../test) directory contains automated test cases written using the 6*80689db1SShawn McCarney[GoogleTest](https://github.com/google/googletest) framework. These tests are 7*80689db1SShawn McCarneyrun during Continuous Integration (CI) testing. 8*80689db1SShawn McCarney 9*80689db1SShawn McCarneyThe goal is to write automated test cases for as much application code as 10*80689db1SShawn McCarneypossible. 11*80689db1SShawn McCarney 12*80689db1SShawn McCarney## Test case conventions 13*80689db1SShawn McCarney 14*80689db1SShawn McCarneyEach implementation source file should have a corresponding tests file. For 15*80689db1SShawn McCarneyexample, [rail.cpp](../src/rail.cpp) is tested by 16*80689db1SShawn McCarney[rail_tests.cpp](../test/rail_tests.cpp). 17*80689db1SShawn McCarney 18*80689db1SShawn McCarneyWithin the tests file, there should be a TEST for each public method or global 19*80689db1SShawn McCarneyscope function. For example, `Rail::configure()` is tested by 20*80689db1SShawn McCarney`TEST(RailTests, Configure)`. 21*80689db1SShawn McCarney 22*80689db1SShawn McCarney## Mock framework 23*80689db1SShawn McCarney 24*80689db1SShawn McCarneyOne of the primary challenges with automated testing is handling external 25*80689db1SShawn McCarneyinterfaces. The `phosphor-regulators` application depends on the following 26*80689db1SShawn McCarneyexternal interfaces: 27*80689db1SShawn McCarney 28*80689db1SShawn McCarney- D-Bus 29*80689db1SShawn McCarney- Error logging 30*80689db1SShawn McCarney- Hardware presence 31*80689db1SShawn McCarney- Hardware Vital Product Data (VPD) 32*80689db1SShawn McCarney- Journal 33*80689db1SShawn McCarney- Sensors 34*80689db1SShawn McCarney 35*80689db1SShawn McCarneyThese interfaces are either not available or do not behave properly within the 36*80689db1SShawn McCarneyCI test environment. Thus, in automated test cases they need to be mocked. 37*80689db1SShawn McCarney 38*80689db1SShawn McCarneyThe GoogleTest mock framework is used to implement mocking. This allows the 39*80689db1SShawn McCarneybehavior of the external interface to be simulated and controlled within the 40*80689db1SShawn McCarneytest case. 41*80689db1SShawn McCarney 42*80689db1SShawn McCarneyThe mock framework typically relies on a class hierarchy of the following form: 43*80689db1SShawn McCarney 44*80689db1SShawn McCarney- Abstract base class with virtual methods for external interfaces 45*80689db1SShawn McCarney - Concrete sub-class with real implementation of virtual methods that call 46*80689db1SShawn McCarney actual external interfaces 47*80689db1SShawn McCarney - Mock sub-class that provides mock implementation of virtual methods 48*80689db1SShawn McCarney 49*80689db1SShawn McCarney`phosphor-regulators` follows this pattern using the following classes: 50*80689db1SShawn McCarney 51*80689db1SShawn McCarney- [Services](../src/services.hpp) 52*80689db1SShawn McCarney - [BMCServices](../src/services.hpp) 53*80689db1SShawn McCarney - [MockServices](../test/mock_services.hpp) 54