You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some testing scenarios it can be handy to generate a binary that is able to populate it's own test database. A prerequisite for this is to bundle the fixture files with the binary. One possible way to do so is packr. But there is no straightforward way to make the bundled files available for the testfixtures package.
Luckily packr implements http.FileSystem in order to represent the bundled files in the binary. I therefore suggest to add the following functions to testfixtures:
I used embedding tools like fileb0x a lot, but for production stuff like assets and HTML templates. I found it very curious that you want to use it for testing stuff.
I have no opposition to adding a function that accepts http.FileSystem, though. I'd be happy to review a pull request for it. 🙂
Something to keep in mind is that it may be necessary to add an additional directory parameter to that function, otherwise users won't be able to load fixtures if they're not in the root directory.
For some testing scenarios it can be handy to generate a binary that is able to populate it's own test database. A prerequisite for this is to bundle the fixture files with the binary. One possible way to do so is
packr
. But there is no straightforward way to make the bundled files available for thetestfixtures
package.Luckily
packr
implementshttp.FileSystem
in order to represent the bundled files in the binary. I therefore suggest to add the following functions totestfixtures
:This would allow
testfixtures
to work together withpackr
or other sources for fixture files that implement the http.FileSystem interface.The text was updated successfully, but these errors were encountered: