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.
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 aDefaultClientvariable that is automatically loaded to maintain current behaviour.Something like:
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.