Real world, understandable scenarios, with complexity built-in.
I think of these scenarios as being slightly different from standard integration tests. They are more akin to acceptance tests, but without the implication that the system be used by the exact same mechanism that an end-user would use it. For example, in many cases people can only drive truly complex scenarios for web applications by using the browser. That's a level of integration too far. I prefer to write-view-model-tests-at-the-level-of-intent, for example. They are still extremely high-level, but do not force tremendous loss of speed associated with traditional acceptance tests.
If you don't do that stuff this way, then you have to test these scenarios manually. It's very difficult to get the system into the place where you can test complex interactions. Because of that, you will not be inclined to look for the very difficult interaction problems, and as they come in one-by-one from real-world bugs, you will fix them, but not have a holistic overview of the behavior of the system.
If the integration tests are fast, then you can run them very often, and you can test at a higher level of abstraction. blog-post-test-units-not-classes
An aim with the high level scenarios is:
Other people can enter the module and clearly see the requirements at the higher level
The common rigorous distinction between unit tests and so-called integration tests is misleading. Integration tests can be fast, they just typically aren't.
The trouble with having many integration test is that they have a weight to them that integration to that unit test do not have. It can take more effort to alter them as new requirements are added. This is why it's so critical that they are fast, and that you use helpers to DRY up your test code somewhat. The only way to get the integration tests to be fast is to have them also be isolated from real world concerns in the same way that the unit tests are.
In talk-integration-tests-are-a-scam J.B. Rainsburger talks about the combinatorial explosion that testing at a high-level can lead to. Rather than covering every possible case, we should be testing-concept-testing-to-a-level-of-confidence.
Reuse can make sense, but so can copy/paste
Direct translation to Ruby would be simple because of no reliance on other libraries. Maybe not quite as easy as the regex replacements mentioned in podcast-javascript-jabber-146-react, but
podcast-rr-196-testing-clojure-in-ruby
Reuse can make sense, but so can copy/paste and small alterations. Think about purpose-specific libraries that it doesn't make sense to extend, but it does make sense to fork and make slightly different.