karma-failure-snapshots
Karma plugin for taking snapshots of the web browser state whenever a test fails.
If your tests fail in an environment, which is difficult to debug, or if they do not fail during debugging, or if they fail intermittently, this plugin may help you to investigate the problem.
The following favourite test frameworks are supported:
- Jasmine by karma-failure-snapshots-jasmine
- Mocha by karma-failure-snapshots-mocha
- QUnit by karma-failure-snapshots-qunit
Additional frameworks can be supported by adding another plugin that implements the interface.
Table of Contents
- Installation
- Configuration
- Options
- Writing Tests
- Failure Snapshot Format
- Plugin Interface
- Contributing
- Release History
- License
Installation
Make sure, that you have installed Node.js 12 or newer. Then you can install this plugin by NPM or Yarn:
npm install --save-debug karma-failure-snapshots
Usually you will install this plugin together with karma
itself and unit testing frameworks and their plugins. For example, the typical installation for tests using mocha
:
npm install --save-debug karma karma-mocha karma-chai mocha chai
karma-chrome-launcher karma-firefox-launcher \
karma-failure-snapshots karma-failure-snapshots-mocha
See an example how to introduce tests with failure snapshots in a project.
Configuration
This plugin has to be aded to the frameworks
array in the Karma configuration file, usually karma.conf.js
:
frameworks: [ 'failure-snapshots', ... ],
You will add it with an additional plugin supporting your unit test framework, which you will place in front of it. The specific plugins have the naming convention failure-snapshots-<framework>
. When you add other karma framework plugins to support your unit test framework, make sure, that you place the failure snapshot plugins before them. For example, a typical configuration for mocha
:
module.exports = function (config) {
config.set({
frameworks: [
'failure-snapshots-mocha', 'failure-snapshots', 'mocha', 'chai'
],
...
})
}
The failure snapshot plugins extend the unit test framework and that is why it has to be loaded after it. Generally, framework plugins insert their scripts to be loaded by the browser to the beginning. If you place the failure snapshot plugins to the front, the later added test framework plugins will insert their scripts before the earlier added ones. Just follow the reverse order of dependencies among the plugins.
Options
The plugin supports a few options to customize the location to save the snapshots too and other parameters. The following are the defaults:
module.exports = function (config) {
config.set({
...,
// Configure the server-side of the plugin
failureSnapshots: {
failuresDirectory: 'failures', // Relative to the current directory
snapshotNamePadding: 4, // Cover up to 9999 snapshots
summaryTemplate: null // Use the built-in page template
browserDirectory: true // Create a directory for each browser
},
// Configure the client-side of the plugin and its extensions
client: {
failureSnapshots: {
includePassed: false, // Do not take snapshots of passing tests
hideFunctionsFrom: null // File names to omit from call stacks; let
// the specific test framework set this
}
}
})
}
Option | Default | Descripton |
---|---|---|
failuresDirectory |
"failures" | Snapshots and the summary will be written there. It will be cleared on each test run. |
snapshotNamePadding |
4 | Length of the snapshot file name, left-padded by zeros. Snapshots are numbered from one by incrementing a counter. |
summaryTemplate |
null |
File with a Handlebars template of the summary page. See the built-in page for more information. |
browserDirectory |
true |
Create a sub-directory for each browser inside failuresDirectory
|
includePassed |
false |
Can enable taking snapshots of passing tests too. Probably for experimental purposes. |
hideFunctionsFrom |
null |
Array of file names to ignore from stacktraces formatted by the unit test framework. Framework plugins supply this value, but you might have a custom one, or you might want to omit more stack frames. |
Writing Tests
Usually you will not need to modify your tests. The snapshots will just be taken, once a test spec fails or throws an unexpected error. For example, a typical test using mocha
with set-up and tear-down phases.
describe('test suite', function () {
before(function () {
// Render a component in the document body
})
after(function () {
// Clean up the document body
})
it('test spec 1', function () {
...
})
...
})
The automatic snapshot taking is using the afterEach
hook of the particular unit test framework. If you implement this hook and perform a page clean-up, which would remove content important for inspection, the snapshot will be taken after your clean-up and thus not be useful:
describe('test suite', function () {
beforeEach(function () {
// Render a component in the document body
})
afterEach(function () {
// Clean up the document body
})
it('test spec 1', function () {
...
})
...
})
If you have such clean-up, insert an additional afterEach
hook before the clean-up, which will make the snapshot of the problem:
describe('test suite', function () {
beforeEach(function () {
// Render a component in the document body
})
// Ensure that a snapshot is taken immediately in case of failure
afterEach(window.ensureFailureSnapshot)
afterEach(function () {
// Clean up the document body
})
it('test spec 1', function () {
...
})
...
})
The ensureFailureSnapshot
will take a failure snapshot only if there is a failure. If there is no failure, this function will return without doing anything.
Failure Snapshot Format
A failure snapshot consists the following two parts:
-
Snapshot - document content of the current window (content of the
<html>
element) -
Screenshot - picture of the current window (content of the
<body>
element)
All failure snapshots are stored in a directory with a summary. The summary is a HTML page listing all failed tests and linking them to their failure snapshots. It includes messages and stacktraces too.
failures/
snapshots/
0001.html
0001.png
0002.html
0002.png
...
index.html
Plugin Interface
Plugins are supposed to all the method collectFailureSnapshot
to collect information about a failure snapshot. If taking a snapshot has to be done earlier, than the collection, takeFailureSnapshot
can be called separately and its output passed to collectFailureSnapshot
. (takeFailureSnapshot
is asynchronous and if its output is passed to collectFailureSnapshot
, the latter will run synchronously.) Both methods are exposed in the window.__failure_snapshots__
object.
Failure snapshots are usually taken from an afterEach
hook, which can be asynchronous. It is essential to take them right after a test failed, so that the web page can be inspected while it still shows the failure.
See the mocha plugin as an example how to write a custom one.
collectFailureSnapshot(data: Object [, done: Function]): none|Promise
The data
argument is an object with the following properties:
{
description: "the full description of the test spec",
stack: "message and stacktrace of the failure",
snapshot: "HTML content of the document element",
screenshot: "Base64-encoded PNG content of the window screenshot",
failure: <boolean flag if the test failed>,
pass: <boolean flag if the test succeeded>,
earlySnapshot: <optional object returned by takeFailureSnapshot>
}
The done
argument is a function to be called, when the failure snapshot collection has finished. It will be called in both asynchronous or synchronous execution cases.
Returns a promise, which you can wait for, if it runs asynchronously. If it runs synchronously, the result is unspecified and not a promise.
takeFailureSnapshot(): Promise
Returns a promise to an object, which is supposed o pass to the data
argument for collectFailureSnapshot
as the earlySnapshot
property.
Contributing
In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using Grunt.
License
Copyright (c) 2019-2022 Ferdinand Prantl
Licensed under the MIT license.