You're right -- this test doesn't actually test the 10-minute timeout. I kind of stepped across my branches here, because in the branch where I'm working on for refactoring the ring_view, I had gotten rid of that timeout entirely. I added this test in the expectation that as soon as I land the refactor, the 10-minute timeout would no longer be relevant. What it does test is that the alarm screen actually shows up, and that the user can dismiss the alarm -- something we (alarmingly!) didn't test before in an integration test.

That said, the way to reproduce the glitch caused by this issue is to modify the timeout in RingView, to cut it down from 10 minutes to a few seconds; but because this view pops up as the result of an alarm firing, it's difficult to modify that parameter from an integration test without actually changing the behavior to pass a timeout from the parent window. To me, that seems unnecessary given that the timeout will not exist when I land the ringview refactor (which should happen within the next couple of weeks).

If you're still set on having me add an integration test to verify the 10-minute idle, I can do it, but when the ringview refactor removes the timeout, that test would essentially become the test we have now.