Interesting! This is definitely good food-for-thought, thank you! (At current gig, seems even more clear that we're not making good uses of contexts/etc; both i

Interesting! This is definitely good food-for-thought, thank you! (At current gig, seems even more clear that we're not making good uses of contexts/etc; both in the sense that we're not using them, and that when we use them we're not using them like this). It does seem like this can cover a bunch of what I usually turn to Cucumber for - the higher-level descriptions - although I think it reinforces how I generally like to use it: for the multi-step full user flow integration "tests" (leaning heavily towards the "this is a product description" and away from "these should be comprehensive"). That is: use something like RSpec to get your ~100% test coverage via unit tests, and then use Cucumber to both (1) ease communication with what a feature does, and (2) exercise all the code involved in a main user path. TL;DR - Seems like the happiest path is something like (1) unit tests that barely use contexts, (2) integration (request, controller) tests that heavily use contexts (your examples), (2) feature (cucumber) tests for multi-step feature flows. Unit tests should aim for 100% coverage (but it's OK to miss); integration tests should aim to cover 100% of the different kinds of situations that are encountered (; feature tests should aim to communicate what users actually do. PS - haha, if you're still at Datadog, talking with a colleague of yours on the sales side about switching from New Relic to y'all. Knowing this quality of code is under there is a a definite point in your favor :)