Simon icon Simon
Flexible server monitoring

Dependencies for Tests

Another thing that I miss in Simon that WhistleBlower had is Dependencies for Tests; I think it would be a great feature for Simon (unless I'm missing something and it's already there).

The feature creates a dependency between Tests, so that if one Test has failed, other Tests that depend on it will pause themselves rather than report their own failures.

For example, I have a Test for a sync server by making sure that a port is open and responding correctly. There are a bunch of dependent tests that check the sync server's log to see if various users are syncing correctly. If the main port-based Test has failed, I don't want to get failures from all the other tests too: it's just noise at that point.

I think this could be implemented in the "Pause" section: in addition to the current schedule-based pauses, you could add a pause like "If Test has Failed", being able to choose another existing Test name, as well as an optional "Additional Delay After Recovery" in minutes. Whenever that other Test has failed, the current Test pauses itself. When the other Test recovers, then the current Test resumes, after the "Additional Delay After Recovery" time.

David Sinclair's picture

Re: Dependencies for Tests

Test dependencies is something I plan to add in a future version (after 2.6), via the planned groups feature. I'm still working out the details, but the current idea is that you'll be able to specify notifiers for the group as a whole, so any change, failure or recovery of any test within the group uses those notifiers, thus you'll only get one failure notification as you wish.

Specifying dependencies in the Pause section is a good idea, but I think using groups would be more flexible. It'd be easier to drag tests into a group than to edit several tests (though I also have plans to make it easier to edit several tests at once).

JohnDCCIU's picture

Re: Dependencies for Tests

The Groups feature sounds great, as long as there is the ability to set the order of the tests in a group, so that the lower-level Test could run first and be the one that gets reported for the Group if it fails. It wouldn't make sense to have one of the higher-level tests (what I was calling a Dependent Test) happen to run first and be the one that gets reported, when the lower-level test was the one that actually failed.