Closed jensneuse closed 5 years ago
I was thinking the same thing! I've just got into Golang and I've been playing with golden tests.
FWIW: I've build this golang test setup for a CLI app:
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
dir, err := os.Getwd()
if err != nil {
t.Fatal(err)
}
cmd := exec.Command(path.Join(dir, binaryName), tt.args...)
output, err := cmd.CombinedOutput()
if err != nil {
t.Fatal(err)
}
if *update {
writeFixture(t, tt.fixture, output)
}
actual := string(output)
expected := loadFixture(t, tt.fixture)
if !reflect.DeepEqual(actual, expected) {
dmp := diffmatchpatch.New()
diffs := dmp.DiffMain(actual, expected, false)
t.Errorf("\nGolden file comparison failed!\nDiff is below:\n" + dmp.DiffPrettyText(diffs))
}
})
}
Giving something like this:
Obviously having this within goldy as a helper method would be neat. Maybe a new method compareWithDiff
or something?
I've build a similar "script". https://github.com/jensneuse/diffview I wouldn't call this code but it works fine for me. If I'd were to integrate this I'd make it a bit abstract so that one can implement diffent diff viewers if they like. Then there need to be some kind of configuration, e.g. via ENV, to set the diffviewer.
I use this workaround
Json formatting / indenting reference: https://github.com/sebdah/goldie/pull/12
@jensneuse @petems @shrkamat I forked the repo and made a bunch of changes (structure-wise), but diffs are now supported. Here's an example of how you could enable that feature:
func TestNewExample(t *testing.T) {
g := goldie.New(
t,
goldie.WithDiffEngine(goldie.ClassicDiff), // ClassicDiff, ColoredDiff
goldie.WithFixtureDir("test-fixtures"), // In case you want a different directory
goldie.WithTestNameForDir(true), // Creates a directory in fixture directory per test
)
g.Assert(t, "example", []byte("my example data"))
}
The new structure leverages the functional options pattern.
NOTE: The default fixture directory is now testdata
.
If this were ever to be merged into the main project, it would definitely need a "breaking changes v2.0.0" warning due to the restructuring.
Hmm, interesting stuff guys. Sorry for the long absence, have been in a little over my head lately.
My gut reaction is that this is a positive change. @gtrevg if you could raise a PR on this I'll take a look. As long as we are clear in our communication, I don't think a breaking change would be too bad for this.
@sebdah No worries about the lack of response man, I appreciate the work you've done! 🤝
@sebdah No worries! Thanks for building the package in the first place!
I'll make a PR to the repo with the changes. It might make sense to tag the current master branch with a v1.0 or something. Then people can always pull in the v1.0 version if they don't want the breaking changes.
Thanks!
@gtrevg Thanks for implementing this. It has just now been merged to master
with the v2.0.0
release.
I'm regularly using this tool for regression tests. While using I found a typical use case that's not yet perfectly covered. I'm often pretty printing structs to json, e.g. to regression test the output of an adapter. It regularly happens that I have to split the output into two files and use an external tool to diff view the expected value vs. the actual value to quickly identify the change.
I'd like to add to your api another method/option to output as diff view. Do you like to add this feature or are you open to pull requests?