docs/devel/ci-definitions.rst.inc

   1 Definition of terms
   2 ===================
   3
   4 This section defines the terms used in this document and correlates them with
   5 what is currently used on QEMU.
   6
   7 Automated tests
   8 ---------------
   9
  10 An automated test is written on a test framework using its generic test
  11 functions/classes. The test framework can run the tests and report their
  12 success or failure [1]_.
  13
  14 An automated test has essentially three parts:
  15
  16 1. The test initialization of the parameters, where the expected parameters,
  17    like inputs and expected results, are set up;
  18 2. The call to the code that should be tested;
  19 3. An assertion, comparing the result from the previous call with the expected
  20    result set during the initialization of the parameters. If the result
  21    matches the expected result, the test has been successful; otherwise, it has
  22    failed.
  23
  24 Unit testing
  25 ------------
  26
  27 A unit test is responsible for exercising individual software components as a
  28 unit, like interfaces, data structures, and functionality, uncovering errors
  29 within the boundaries of a component. The verification effort is in the
  30 smallest software unit and focuses on the internal processing logic and data
  31 structures. A test case of unit tests should be designed to uncover errors due
  32 to erroneous computations, incorrect comparisons, or improper control flow [2]_.
  33
  34 On QEMU, unit testing is represented by the 'check-unit' target from 'make'.
  35
  36 Functional testing
  37 ------------------
  38
  39 A functional test focuses on the functional requirement of the software.
  40 Deriving sets of input conditions, the functional tests should fully exercise
  41 all the functional requirements for a program. Functional testing is
  42 complementary to other testing techniques, attempting to find errors like
  43 incorrect or missing functions, interface errors, behavior errors, and
  44 initialization and termination errors [3]_.
  45
  46 On QEMU, functional testing is represented by the 'check-qtest' target from
  47 'make'.
  48
  49 System testing
  50 --------------
  51
  52 System tests ensure all application elements mesh properly while the overall
  53 functionality and performance are achieved [4]_. Some or all system components
  54 are integrated to create a complete system to be tested as a whole. System
  55 testing ensures that components are compatible, interact correctly, and
  56 transfer the right data at the right time across their interfaces. As system
  57 testing focuses on interactions, use case-based testing is a practical approach
  58 to system testing [5]_. Note that, in some cases, system testing may require
  59 interaction with third-party software, like operating system images, databases,
  60 networks, and so on.
  61
  62 On QEMU, system testing is represented by the 'check-avocado' target from
  63 'make'.
  64
  65 Flaky tests
  66 -----------
  67
  68 A flaky test is defined as a test that exhibits both a passing and a failing
  69 result with the same code on different runs. Some usual reasons for an
  70 intermittent/flaky test are async wait, concurrency, and test order dependency
  71 [6]_.
  72
  73 Gating
  74 ------
  75
  76 A gate restricts the move of code from one stage to another on a
  77 test/deployment pipeline. The step move is granted with approval. The approval
  78 can be a manual intervention or a set of tests succeeding [7]_.
  79
  80 On QEMU, the gating process happens during the pull request. The approval is
  81 done by the project leader running its own set of tests. The pull request gets
  82 merged when the tests succeed.
  83
  84 Continuous Integration (CI)
  85 ---------------------------
  86
  87 Continuous integration (CI) requires the builds of the entire application and
  88 the execution of a comprehensive set of automated tests every time there is a
  89 need to commit any set of changes [8]_. The automated tests can be composed of
  90 the unit, functional, system, and other tests.
  91
  92 Keynotes about continuous integration (CI) [9]_:
  93
  94 1. System tests may depend on external software (operating system images,
  95    firmware, database, network).
  96 2. It may take a long time to build and test. It may be impractical to build
  97    the system being developed several times per day.
  98 3. If the development platform is different from the target platform, it may
  99    not be possible to run system tests in the developer’s private workspace.
 100    There may be differences in hardware, operating system, or installed
 101    software. Therefore, more time is required for testing the system.
 102
 103 References
 104 ----------
 105
 106 .. [1] Sommerville, Ian (2016). Software Engineering. p. 233.
 107 .. [2] Pressman, Roger S. & Maxim, Bruce R. (2020). Software Engineering,
 108        A Practitioner’s Approach. p. 48, 376, 378, 381.
 109 .. [3] Pressman, Roger S. & Maxim, Bruce R. (2020). Software Engineering,
 110        A Practitioner’s Approach. p. 388.
 111 .. [4] Pressman, Roger S. & Maxim, Bruce R. (2020). Software Engineering,
 112        A Practitioner’s Approach. Software Engineering, p. 377.
 113 .. [5] Sommerville, Ian (2016). Software Engineering. p. 59, 232, 240.
 114 .. [6] Luo, Qingzhou, et al. An empirical analysis of flaky tests.
 115        Proceedings of the 22nd ACM SIGSOFT International Symposium on
 116        Foundations of Software Engineering. 2014.
 117 .. [7] Humble, Jez & Farley, David (2010). Continuous Delivery:
 118        Reliable Software Releases Through Build, Test, and Deployment, p. 122.
 119 .. [8] Humble, Jez & Farley, David (2010). Continuous Delivery:
 120        Reliable Software Releases Through Build, Test, and Deployment, p. 55.
 121 .. [9] Sommerville, Ian (2016). Software Engineering. p. 743.