Approval Testing

What

A way of testing code, which has no/little tests
Can use examples given in documentation, to find the output of the code and use this as standard you code after refactoring must meet
Finds a way of getting results of output, to form unit tests, especially useful when code is complex and undocumented.
- This can be used to write a suite of unit tests

Will generally have to run all the code, so no stubs/mocks
For methods that return some output, we store the output in some file and use this file to compare future calls
For side affect methods, ie db/files, can get a snapshot of these changes in some format (file contents, or object) to compare with future calls
For an app, ie webserver, can use a logger/interceptor to record the response sent back to the user
- This includes logging all changes to database, logs, files
- This will be heavy weight, so not great to use all the time

Helps in refactoring legacy (non tested) code
provides safety net while refactoring when there is no test suite
Helps create a test suite
Finds bugs as you refactor, this leads to a discussion point with stakeholders of what to do with them
Good for tinkering with non tested code
- especially if commiting

May need to iteratively create several approval tests, so that you cover all the code paths before refactoring and adding behaviour
- use code coverage tools
Do not change behaviour
- keep bugs and have example approval test for a bug

This can be a cheat way for avoid TDD or real tests, and can end up being stuck in code bases
- should be deleted after use, and behaviour encapsulated in proper tests using a test harness
you shouldn't use approval checks as part of integration tests, as their results change too often, and who's got time to review and approve new results?
approval tests don't really work as proper correctness checks
approval tests shouldn't make up the majority of your tests, far from it
Limited scope: Approval testing only verifies that the output of the software matches the expected output for a given set of inputs. It does not verify the functionality or performance of the software beyond that.
Manual effort: Approval testing can require manual effort to create and approve the expected output, which can be time-consuming and error-prone.
High maintenance: Approval tests can become difficult to maintain as software changes over time. When the software changes, the expected output may need to be updated, which can be tedious and time-consuming.
False positives: Approval testing can produce false positives if the expected output is not updated to reflect changes in the software.
Limited applicability: Approval testing is not suitable for all types of software, particularly software that does not have deterministic output or where the output is difficult to predict.