Encapsulate Snapshots as collection

[b5]

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.

[sjkaliski]

I like this! And it makes updating config easier as the package evolves over time. Will think over tonight.

Mind elaborating on the use case of multiple instances?

[b5]

As for multiple use cases, a nice example would be having one .snapshots file per API version, Or cutting up sections of an API into separate files. As you'd mentioned, each could have different configurations, making things a little more decouple-able.

[sjkaliski]

Makes sense. So long as there are sane (and equivalent) defaults, no reason to not provide additional functionality.

Something like this perhaps?

v1Snapshots := &Snapshots{
  Dir: "testdata/v1",
}
v1Snapshots := &Snapshots{
  Dir: "testdata/v2",
}

// ... in some test

v1Snapshots.AssertHTTPResponse(t, "example route v1", res1)
v2Snapshots.AssertHTTPResponse(t, "example route v2", res2)

[sjkaliski]

@b5 still interested in this?

[b5]

I am, but sadly have zero bandwidth to take on shipping this feature 😢. Considering this has been open for more than 6 months, might be worth closing?