bradleyjkemp / cupaloy Goto Github PK

Otherwise Github includes these in the language statistics and so might tag a HTML generating package as a HTML project rather than a Go one.

Currently the non-existent snapshot tests create some temp directories. These are harmless but could definitely be deleted automatically

Debugging large snapshot changes in the terminal is difficult. #64 could help but you might still want to view the two files side by side.

Suggested solution is adding a new flag/option that writes failing snapshots to a file with an extra suffix e.g. .failed

Requested by @thecodejunkie: https://twitter.com/TheCodeJunkie/status/1388797594521022464

Add some tests for when SnapshotT is called on a changed value and ensure that this would fail the test.

Slightly non-trivial because we need to mock testing.T in order to check that this would fail the user's test but without failing our test but should be pretty simple with something like github.com/matryer/moq

Add option to choose this.
Currently they are just errors but this is perhaps unexpected behaviour if the test case continues after the snapshot is taken.

This seems to be the behaviour of other libraries

A recent commit jf-tech/omniparser@1b4997b introduced a snapshot filename containing ;. While itself is fine, i.e. running tests is all good, we ran into issues when the module being imported by 3rd party, hitting an error:

extensions/omniv21/fileformat/flatfile/fixedlength/.snapshots/TestReadAndMatchHeaderFooterBasedEnvelope-empty_buf;_single_line_header-footer_match: malformed file path "extensions/omniv21/fileformat/flatfile/fixedlength/.snapshots/TestReadAndMatchHeaderFooterBasedEnvelope-empty_buf;_single_line_header-footer_match": invalid char ';'

Turns out ; isn't allowed in module filepath: https://cs.opensource.google/go/x/mod/+/master:module/module.go;l=285;drc=02c991387e35f9e4c0a9b7ce137717055f8d716d

Your library already does many of the special character replacement during snapshot file creation. Wondering if ; semicolon can be added?

Cheers!

Allow something of the form:

cupaloy.WithOpt(cupaloy.ErrorMessage("blah")).SnapshotT(t, result)

Where the given functional option only applies to that invocation. This makes using options less verbose when you only need to use them once and makes Snapshotter structs more useful because they can be temporarily modified.

Currently docs suggest that WithOptions modifies the original whereas the actual semantics are that the original is unchanged and returns a clone with the options applied.

I am getting inconsistent test failures. The difference is sometimes there are single spaces in the snapshot of a variable, and sometimes there are double spaces. Any ideas on why or how to fix? Thanks.

From go.sum

github.com/bradleyjkemp/cupaloy v2.3.0+incompatible h1:UafIjBvWQmS9i/xRg+CamMrnLTKNzo+bdmT/oH34c2Y=
github.com/bradleyjkemp/cupaloy v2.3.0+incompatible/go.mod h1:Au1Xw1sgaJ5iSFktEhYsS0dbQiS1B0/XMXl+42y9Ilk=
...
github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c=
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=

The first example should really be the basic use of using SnapshotT and not requiring stretchr/testify, etc.

We are currently tied to using an environment variable to control snapshot updating. Some people are used to using cli flags so would be nice to be able to support this.

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

I would like to have multiple snapshots from tests cases in table driven tests. For that, I would need a combination of SnapshotMulti and SnapshotT. Would it make sense to have an additional SnapshotTMulti or SnapshotMultiT functions?

var testCases = map[string][]string{
    "TestCaseOne": []string{......},
    "AnotherTestCase": []string{......},
    ....
}

for testName, args := range testCases {
        t.Run(testName, func(t *testing.T) {
                myMock := MyMock{
                         MockFunc: function (input string) {
                                cupaloy.SnapshotTMulti(t, "input", input)
                         },
                }
                result := functionUnderTest(myMock, args...)
                cupaloy.SnapshotTMulti(t, "result", result)
        })
}

Another possibility would be that the *testing.T can be passed into the constructor of Cupaloy (This is how https://github.com/matryer/is works):

var testCases = map[string][]string{
    "TestCaseOne": []string{......},
    "AnotherTestCase": []string{......},
    ....
}

for testName, args := range testCases {
        t.Run(testName, func(t *testing.T) {
                cupaloy := cupaloy.New(cupaloy.T(t))

                myMock := MyMock{
                         MockFunc: function (input string) {
                                cupaloy.SnapshotMulti("input", input)
                         },
                }
                result := functionUnderTest(myMock, args...)
                cupaloy.SnapshotMulti("result", result)
        })
}

We support anything go-spew supports so just copy some documentation from there

Sourcegraph unexpectedly removed the used-by badge feature replacing it with a dummy value.
Find a replacement or remove the badge from the readme.

Currently we use a raw text snapshot format. If we moved to something like JSON then we could version this to allow for breaking changes to the snapshot format without breaking everyone's tests.

Pass t as argument and use t.Name()

The built in error message is very opaque (necessary because it has to be generic) but users can likely provide a more helpful friendly message customised to their tests (or e.g. when the diff just isn't useful). Therefore an option to customise this message would be useful.

This would only really be usable once #28 is implemented.

Snapshot and SnapshotMulti are not deprecated but for most cases they are the wrong choice (too easy to forget to check the return value and hence tests always pass).
They do have their uses but it should be made clear in the docs that SnapshotT should be used with preference.

I'm trying to snapshot a struct whose one of its fields is a map. Sometimes the test passes, at other times it doesn't. Go maps are randomly sorted by default. However, go-spew has a SortKeys configuration that solves this problem, but it doesn't seem to be used here.

I'm sorry if I'm missing something here, I didn't read the source code so I'm guessing it's a bug and which bug it is, but I might have missed some docs.

Thanks nonetheless!

The badge endpoint takes a long time to respond and so cloudflare returns a 500, this then seems to get cached by GitHub as a broken/missing image.

See https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis

Be able to distinguish between created/updated and mismatch errors using interfaces: https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully

docs here https://pkg.go.dev/github.com/pyros2097/cupaloy#section-readme
say use

go get -u github.com/bradleyjkemp/cupaloy

README on here doesn't even mention how to install. Not even sure if same package.

I get

go get: module github.com/bradleykemp/cupaloy: git ls-remote -q origin in /Users/kevin/.go/pkg/mod/cache/vcs/80d9f6d7d4a4bdada3cd1ba5dfc1c3543d1449b3cb2ccd046ae294400d51c447: exit status 128:
	fatal: could not read Username for 'https://github.com': terminal prompts disabled
Confirm the import path was entered correctly.

No other package in my current project is having this problem.

However, I got a clue from pkg.go.dev docs

go get github.com/pyros2097/cupaloy

which worked.

Some struct fields might be known and intended to not remain constant between test runs. It would then be required to ignore these fields (perhaps just by overwriting with a constant value)
Arguably tests should be deterministic though.

Jest has a great feature for matching specific types for fields: https://jestjs.io/docs/snapshot-testing#property-matchers

It would be great if this library also support this.

Currently the diffing tool used by Cupaloy treats strings as just a sequence of characters. Which is reasonable, but limited.

In particular, it would be fantastic if there were a way to tell it to treat the two strings as JSON. Which would mean:

• Whitespace is ignored
• Object keys are unordered

That way, any changes to the output that are changes to the raw string but are not meaningful changes to the JSON structure are ignored and will not cause the tests to fail.

In particular, I've had an issue where VSCode auto-formats the JSON within a snapshot file when I'm making changes to it, which then means that everything breaks. Often it actually means it's quicker to delete the file and regenerate it rather than just fixing up one value that's changed because of a code change.

Raw strings don't really need to be spewed. We should support snapshotting strings directly

After installing this package using govendor running the tests it fails with the error

package command-line-arguments (test)
        imports github.com/bradleyjkemp/cupaloy
        imports github.com/bradleyjkemp/cupaloy/v2/internal: use of internal package github.com/bradleyjkemp/cupaloy/internal not allowed
FAIL    command-line-arguments [setup failed]

While writing a bunch of tests, I noticed that Cupaloy will still write snapshots on the first invocation of a test, even if that test has already failed. For instance:

func TestShouldNotWriteSnapshot(t *testing.T) {
	t.Fail()
	cupaloy.SnapshotT(t, "bad snapshot")
}

will still log:

--- FAIL: TestShouldNotWriteSnapshot (0.00s)
	board_test.go:199: snapshot created for test TestShouldNotWriteSnapshot

and write a snapshot to .snapshots/TestShouldNotWriteSnapshot.

I'm not sure if this is the intended behavior or not, but it seems like a bad idea to write snapshots for a test that is known to have failed. Maybe we should check t.Failed() inside cupaloy.SnapshotT?

This can hide significant portions of the result being spewed and unnecessarily ties snapshots to the (designed for users) String() implementation.

This should just involve setting DisableMethods: true in the Spew config but we need to check that this isn't going to affect any known users (https://github.com/search?l=Go&o=desc&q="bradleyjkemp%2Fcupaloy"&s=indexed&type=Code) i.e. that no one is currently snapshotting types implementing the Stringer interface