Snapshot testing is an extension of usual expected-vs-actual assertion where the following conditions apply:
In the case of TEAMMATES, snapshot testing is useful for the following comparisons:
Snapshots testing can run in two modes, namely, verification mode (default) and auto-update mode.
In verification mode, snapshot testing is essentially the same as a normal expected-vs-actual assertions, where the actual object is compared against the snapshot.
Auto-update mode is the flagship feature of snapshot testing. Essentially, this reverses the process of testing, i.e. using the actual generated object to overwrite the snapshot provided in the test. To remove redundancy, even if auto-update mode is enabled, this overwriting procedure only happens when a test fails during the test run.
For such testing method to be effective, before the changes are committed, a manual verification by the developer is mandatory to ensure only the intended changes have occurred.
For the web page comparison and CSV content generation, the tests are done in the frontend using Jest. Jest has native support for snapshot testing (in fact, that is where the name is obtained from!). Auto-update mode is activated by pressing u
when running Jest under watch mode. More details on updating snapshots in the frontend tests can be found here.
For email generation, the tests are done in the backend. Auto-update mode is activated by setting the value of test.snapshot.update
to true
in test.properties
.
Snapshot testing is typically used in the following two situations:
The following example describes the behaviour of snapshot testing and how it can be used in practice. Let us consider the case where the following line of test code is executed:
expect(fixture).toMatchSnapshot();
Here are three possible situations and the corresponding behaviours of snapshot testing when the test is executed with auto-update mode enabled:
If the snapshot exists and has the correct content, no updates to the source file will be observed.
If the snapshot exists but has the wrong content, it will be updated with the correct content. Subsequently, the test case will pass subsequent test runs with/without auto-update mode enabled.
If the snapshot does not exist, it will be created with the given name (in Jest it is auto-generated) AND with the correct content. Subsequently, the test case will pass subsequent test runs with/without auto-update mode enabled.
The same idea applies to email content test:
EmailChecker.verifyEmailContent(email, recipient, subject, "/studentCourseJoinEmail.html");
Snapshot testing is useful for regression testing, e.g. if a change to frontend logic caused the rendered HTML to change, snapshot testing will reflect those changes and it can be checked whether those changes are intended or not.
However, snapshot testing should NOT be used to check how a rendered HTML looks like before/during/after interactions, e.g.:
Such (mis-)usage of snapshot testing will erode the value of test as the difference between the two snapshots cannot be traced.
In such a case, normal assertions should be used, e.g. by checking the component's internal data before and after the 'click'.
<div>
<span>
<img>
</span>
</div>
being changed to
<div>
<div>
<span>
<img>
</span>
</div>
</div>