It's been a while since this was posted. Hopefully the information in here is still useful to you (if it isn't please let me know!). If you want to get the new stuff as soon as it's out though, sign up to the mailing list below.Join the Mailing list
One of the undeniable benefits of functional testing is regressions. It’s not a foregone conclusion that functional (unit) or other kinds of testing that are recently gaining traction are worth the trouble that they cause (and there are lots of other issues with how you test, what you can test, etc), but I don’t think many people argue about the usefulness of tests when it comes to regressions. I also think that it’s a great thing to have that encourages developer discipline.
In a bid to strengthen my developer discipline (and to stop the nagging in my head), I started adding some unit tests to an app I was already developing, and quickly came upon the trouble of fixtures, and needing some data to generally bootstrap your tests. As many of my projects these days use RethinkDB, I became particularly interested (read: obssessed) with having an easy way to spin up rethinkdb instances, databases, and tables easily for testing out my API (combining what I eventually would develop with something like nodejs’s supertest to really shakedown an API I was developing.
After a more than a few hours feeling my way around how I wanted this solution to look, and working out the implementation bugs, I finally had something that worked at least a little like I had imagined it, check it out (it’s also available as a gist here: fixtures.js):