This was really written to help with unit tests, but perhaps you will find that the same rules apply (more or less) to integration tests:
Check out Seven Steps!
My preference is that whatever you call it, it's really the test suite name (fixture name on our card), the effect you're checking, and the assertion message that need to stand out and make the cause of the error clear. If you find that's easiest with Asherove's naming, then I wholeheartedly endorse that. But maybe the trick is you fill in the "method" part with whatever makes the condition, result, and exception make sense.
I'm happy to see a suite named "MakingADeposit" with a test called "AccountDoesntExist" and an error that says "Expected NonesuchAccount exception - none received."
Alternatively if you don't mind me separating the test suite name with "::", I'm okay with "AccountHandling::MakingADeposit_AccountDoesntExist_ThrowsAnException"
The card also suggests that if you don't have a good name, continue onward and give a better name when one occurs to you (hopefully well before submitting the code to CI).