Regression Testing

With unit testing in mind, developer will consciously design a program that is highly modular#. Regression Testing# could be implemented to further enhance the validity of the written unit tests to see whether they are adhered to the specified requirements.

It is easier to test using plain text as a mean to store synthetic data since it is easy to add, update or modify. There is no need for a dedicated tool to it. For 202206201335#, if its output is in plain text, the analysis can be trivial by just comparing the difference to the previous version of the file, or if necessary, pass it to Perl, #python or other scripting languages.

Utilise the build system (in the book Makefile) to build, generate code or documentation and run 202206201335#.

Both Unit Testing and Integration Testing should be composable; that is, a test can be composed of subtests of subcomponents or subsystems to any depth, so that we can easily select which kind of tests that we should run without involving the whole code base. You can add in Regression Testing# to enforce this practice.

The test data for these testing could be collected from real-world (usually user data coming from an existing system, a competitor’s system or a prototype) or artificially created (in order to satisfy the need of large amount of data, to stress the boundary conditions, or exhibits certain statistical properties such as the runtime of an algorithm#). These data can later be used in the Regression Testing#.

Hunt et al. recommends that both Validation and Verification of System Requirements# and Usability Testing# should be done as early as possible. And that Regression Testing# to be incorporated into the build system in order to compare it to the previous build.

Furthermore, 202206201335# can be applied on this kind of testing in order to capture the discrepancy of the performance between the previous version and the current version of the software.

202206201335# could be done on Integration Testing to validate the tests.