added fixtures #8
Conversation
There was a problem hiding this comment.
@markbates this looks nice, added a couple of ideas maybe for the future, thanks for adding me in this review.
| [[scenario.table.row]] | ||
| id = "<%= uuid() %>" | ||
| name = "Mark Bates" | ||
| admin = true |
There was a problem hiding this comment.
It would be great to add a fake data generation helper, probably we could use something like <%= fake("FirstName") %>
There was a problem hiding this comment.
agreed! that would be great. PR please! ;)
| [[scenario.table]] | ||
| name = "widgets" | ||
|
|
||
| [[scenario.table.row]] |
There was a problem hiding this comment.
It would be great if we could do something like loops for rows
There was a problem hiding this comment.
it's plush, so you can! :)
| } | ||
|
|
||
| func Test_ActionSuite(t *testing.T) { | ||
| action, err := suite.NewActionWithFixtures(App(), packr.NewBox("../fixtures")) |
There was a problem hiding this comment.
Just a thought here: since fixtures are intended to be used in a test context, why do we have to use packr here instead of a regular fs? :)
There was a problem hiding this comment.
Great question! I almost did that, then I went with packr instead. The reason why is when go test runs it does all sorts of stuff with cd and such under the covers. The problem with this is that if you use relative files, the relativity can change. Part of packr's design is based on turning relative into absolute. So using packr means we don't have to worry about those issues.
Another advantage of packr is it opens things up to interesting, programmatic things you can do during your tests, like import someone else box.
TL;DR: relativity can change when running tests; packr doesn't have this problem so it's "safer". :)
No description provided.