> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/testing-reading-maintaining/testing-1/approval-testing.md). # Approval Testing * Golden Master Testing”, “Characterisation Testing” or “Snapshot 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 ## When to use * 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 ## why * 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 ## How * 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 ## Issues * 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. ## Libraries * * * * ## Links * Continuous Delivery - What Is Approval Testing?