Jest: Max Snapshot Line Length

Created on 11 Jun 2019  路  5Comments  路  Source: facebook/jest

馃殌 Feature Proposal

A way to globally configure a max line length for failing a snapshot. A local override should be possible. Similar to setting global timeout and overriding per test case.

Motivation

Snapshots are great for testing results against previous results. Snapshots should be reviewable by humans so when they need to change people understand why. Large snapshots often capture more than what you want to assert on. To prevent this, reducing the object you want to snapshot (or selecting a smaller part of a react tree) should be encouraged in order to reduce noise and boost signal.

Example

jest.MaxSnapshotLines = 10;

expect(bigTree).toMatchSnapShot(); // throws

// second argument
expect(bigTree).toMacthSnapshot(null, 50); // passes

Pitch

It might not belong directly in jest. There is a rule in eslint-config-jest for it already but linting snapshot files feel wrong and can be confusing for developers since they don't tend to directly look at them.

Feature Request

Most helpful comment

馃憢

That's a good point. Having a commit hook that runs lint might help (so you at least discover before committing/pushing), but it's still at a different time.

However, we don't enforce any other "best practices" in Jest, seems like a slippery slope to add support for it for snapshots? Maybe not. But I don't think we have any limiting options to other matchers. E.g. for a strict toEqual we added toStrictEqual rather than toEqual(expected, {strict: true}).


You could build your own toMatchSnapshotWithMaxLines() matcher and add it to jest-extended (or publish separately)? Kinda sorta like https://github.com/satya164/jest-file-snapshot (https://github.com/facebook/jest/issues/6383#issuecomment-425724307).

All 5 comments

second argument is used for property matchers already, so I'm not sure if this is feasible.

Why do you think the eslint rule is confusing?

Unless you add eslint as a jest runner then you're linting at a different time than testing so it would take a separate run of the linter to detect this after you've updated your tests. In this case you would likely get feedback quicker if the configuration lived in jest.

馃憢

That's a good point. Having a commit hook that runs lint might help (so you at least discover before committing/pushing), but it's still at a different time.

However, we don't enforce any other "best practices" in Jest, seems like a slippery slope to add support for it for snapshots? Maybe not. But I don't think we have any limiting options to other matchers. E.g. for a strict toEqual we added toStrictEqual rather than toEqual(expected, {strict: true}).


You could build your own toMatchSnapshotWithMaxLines() matcher and add it to jest-extended (or publish separately)? Kinda sorta like https://github.com/satya164/jest-file-snapshot (https://github.com/facebook/jest/issues/6383#issuecomment-425724307).

@SimenB @palmerj3 Thanks for the guidance!

I ended up creating a custom snapshot serializer that adds a warning to the top of a large snapshot. Let me know if it's worth adding to the jest-community.

https://github.com/jomaxx/jest-large-snapshot-warning

You can add it to awesome-jest :).
Closing this then

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ticky picture ticky  路  3Comments

Secretmapper picture Secretmapper  路  3Comments

ianp picture ianp  路  3Comments

StephanBijzitter picture StephanBijzitter  路  3Comments

withinboredom picture withinboredom  路  3Comments