Last updated: 2020/03/13
The FAFT framework provides a set of python modules that simplifies writing of firmware tests. The design doc was written in 2011 and the code itself has since evolved to support hundreds of firmware tests. This document provides a high level overview of the current code base.
The framework itself is split up into a server side and a client side. The server side runs on the host machine, while the client side runs on the DUT.
The client consists of an XML rpc server that listens for requests from the server side, and a set of utility classes that are able to execute shell commands on the DUT to fulfill the requests.
The server consists of base skeleton autotest test classes that perform DUT initialization and contain references to a set of utility methods and classes that can perform useful actions. Some actions require interaction with the DUT that is not possible via the client RPC server, so these ultimately use servod to carry out the interaction. Others send XML RPC calls to the client on the DUT to perform the needed work.
These are autotest style tests consisting of control file(s) and a test class. The control file documents the test and invokes a job to run the test class. The test class will subclass one of the base test classes, thereby gaining functionality exposed by the framework.
The tests are those prefixed with “firmware_” in site_tests. See firmware_FAFTSetup for a simple example.
This is where the control files and test classes (along with any supporting files) reside under site_tests. It must have the same name as the test class.
The control file specifies metadata and invocation details about the test. If multiple control files use the same test class, the naming convention is control..
The test class contains logic to execute the test. It must be in a module with the same name as the test directory, and the class name must also be the same as the test directory. Its run_once method is allowed to take additional parameters, and these will be populated according to the job invocation in the control files. This facilitates code reuse by allowing multiple control files to share a common test class.
If you’re fixing a bug or adding a new feature to the framework in order to support an immediate need, please write unit and/or integration tests for the code you’ve touched. Adding some additional documentation here or in the code itself may also be helpful.