I wound up repurposing this into a blog post after AssertJS passed it up last year:
The Orchid, the Wasp, and the Test Fixture
Have you ever made a simple, innocent tweak to your API or database schema and realized you'd just rendered dozens or hundreds of barely-related testcases potentially inaccurate? Or worse, have you not realized it before moving on to something else, only to be rudely interrupted by a build failure or a defect report? Maybe you've put off or kludged around a structural change you knew would be far more trouble to test, both directly and indirectly, than it would be to implement. I've been in all three situations more often than I'd prefer to admit. But what can we actually do about it? And what on earth is a rhizome, anyway? Let's borrow from poststructuralist philosophy to rethink data fixtures in an organic, composable way that gives us a better handle on one of the messier aspects of backend testing.
Thanks for sharing your abstract. I'm really glad to hear that you were able to re-purpose this as an opportunity for a blog post!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.