I believe this is from 1.15 on (read a long discussion if you're interested):

$ go test ./...
# github.com/beme/abide
./abide_test.go:25:9: conversion from int to string yields a string of one rune, not a string of digits (did you mean fmt.Sprint(x)?)

The hard coded implementation in assert.go for parsing json responses breaks when using json.NewEncoder([insert-my-struct]).Enocde(w). It asserts that

To reproduce:

type myStruct struct {
    Message `json:"message"`
}

func myHandler(w http.ResponseWriter, r *http.Request) {
    m := myStruct{
        Message: "hello abide"
    }
    json.NewEncoder(w).Encode(&m)
}

if you call assert http response on the above in some test: abide.AssertHTTPResponse(t, name, w.Result()), assert will return an error for unexpected end of JSON input. This is because there's a new line that seems to be returned from httputil.DumpResponse on the json response when using NewEncoder vs using json.Marshal and writing bytes.

assert.go seems to be manually parsing the lines to determine the body, instead it probably makes more sense to actually read the properties from the response rather than the dump from httputil (I think there are a few cases where the dump won't always be consistent - but can't remember off the top of my head)

Building on the changes described in #39 into a more sustainable solution. I think it would make sense to isolate these configuration details into a struct that behaves in a similar way to http.Client, with a DefaultClient variable that is automatically loaded to maintain current behaviour.

Something like:

// Snapshots is a collection of snapshots for testing purposes
type Snapshots struct {
  Dir string
  Ext string
  Separator string
  snapshots map[snapshotID]*snapshot
}

// NewSnapshots creates a Snapshots collection with Default settings
func NewSnapshots() Snapshots {
  return Snapshots{
    Dir: SnapshotsDir,
    Ext: SnapshotExt,
    Separator: snapshotSeparator,
  }
}

// DefaultSnapshots is the default snapshot collection used
// without any additional configuration required
var DefaultSnapshots = NewSnapshots()

This is obviously a big change worth discussing first, but the upside would be the capacity to provision multiple instances of snapshot collections, allowing users to setup & teardown snapshots for versioned API tests in specific test funcs, etc.

I may tackle this one, but want to raise here first.

I think it would be worth converting snapshots map[snapshotID]*snapshot to use sync.Map, or perhaps just use a mutex to protect it. Wondering if there is a preference for minimum golang version that should be targeted, since sync.Map was introduced in golang 1.9. Thoughts?

For context, my use case is a set of tests that assert snapshots from multiple concurrent goroutines. As written, it hits the error: fatal error: concurrent map writes while updating snapshots on github.com/beme/abide/abide.go:230.

• snapshots -> abide
• etc. check all the things

Hey,

Love the library been really helpful in taking snapshot testing to our go libs. I've been trying to use abide.json defaults with code that looks like something like the following:

type UserData struct {
	Name           string `json:"name"`
	Email          string `json:"email"`
}

func TestMyFn(t *testing.T) {
    randNum := rand.Intn(1000000000)
    // we generate random emails as user factories in our tests
    email := fmt.Sprintf("shlomo-%[email protected]", randNum)

    u := []UserData{{"shlomo", email}}
    userBytes, err := json.Marshal(users)
    abide.AssertReader(t, tt.name, bytes.NewReader(userBytes))
}

my abide.json:

{
    "defaults": {
        "email": "foo"
    }
}

but it doesn't seem like abide picks up the defaults and in the snapshot the random email is stored and subsequent tests without an update fail. i define abide.json on the defaults of the lib. Happy to share a larger example if it's helpful.

Thanks!

If a snapshot is out of date and the user wants to automatically update it, passing the -u flag should do so and notify the user that it's been updated.

$ go test -v -- -u

Fantastic tool! Love bringing react concepts into go land 😄.

While go tool has special treatment for directories & filenames that start with .,_, or testdata, the testdata directory it's considered by some to be idiomatic. I know it's a totally irate thing, but would it be great if I could chose to write snapshots to testdata/__snapshots_. One way might be to export the default hardcoded snapshots var. I'd be happy to submit a PR if you're ok with the idea!

It would be awesome to able to be able to specify that you want to assert any arbitrary struct via it's json representation and to pretty print that struct in the snapshot. Right now instead I rely on encoding the struct and then passing it to AssertReader which doesn't pretty print the struct which makes comparisons between snapshots and to visualization json results difficult for large responses.

Use cases for this are larger structs that I would love to be able to assert via json (they never pass through an http endpoint).

I haven't looked through the internals of abide, but would be happy to take a look if it was something that you're interested in adding and we can agree on a correct interface for such an assertion

This package supports asserting arbitrary types so long as they implement the Assertable interface. This feature is not particularly well documented, and #33 highlighted a few common use cases that may be helpful to include.

Pairing with @colinmcardell and explaining the how/why of snapshots it occured to me that it would be really helpful that default case should be a failure.

If no snapshot exists, treat the snapshot as "" such that the new response is logged. Do not capture a snapshot until the user explicitly runs -- -u

Is it possible to replace a dynamic generated HTTP header using the config? I have an Etag HTTP header that is different every time I receive the response (time based).

Because abide library always write the snapshot file here when calling abide.Cleanup() the tests are never cached. Do we need to save those snapshots every time in the cleanup?

abidecache.go

package abidecache

import (
	"encoding/json"
	"net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
	data := map[string]string{
		"foo": "bar",
	}

	body, err := json.Marshal(data)
	if err != nil {
		http.Error(w, err.Error(), http.StatusInternalServerError)
		return
	}

	w.Header().Set("Content-Type", "application/json")
	w.Write(body)
}

abidecache_test.go

package abidecache

import (
	"net/http/httptest"
	"os"
	"testing"

	"github.com/beme/abide"
)

func TestMain(m *testing.M) {
	exit := m.Run()
	abide.Cleanup()
	os.Exit(exit)
}

func TestRequests(t *testing.T) {
	req := httptest.NewRequest("GET", "http://example.com/", nil)
	w := httptest.NewRecorder()
	handler(w, req)
	res := w.Result()
	abide.AssertHTTPResponse(t, "first route", res)
}

Running (snapshots already updated)

➜  go test ./...
ok  	labs/abidecache	0.018s
➜  go test ./...
ok  	labs/abidecache	0.022s

Running (abide.Cleanup commented)

➜  go test ./...
ok  	labs/abidecache	0.018s
➜  go test ./...
ok  	labs/abidecache	(cached)

• json key ordering
• res.Body prettyprint
• offers opportunity for .abide file w/ custom rules

Instead of having a single snapshot directory and file each directory should have it's own snapshot directory and each test file should have it's own snapshot file, e.g.

main.go
main_test.go
__snapshots__/
  main.snapshot
models/
  user.go
  user_test.go
  post.go
  post_test.go
  __snapshots__/
    user.snapshot
    post.snapshot