Kaseya Community

Test driven development in VSA

  • Hey all,

    Historically I have had to create agent procedures to work around limitations of the kaseya monitor alert templates and logic limitations. These procedures are not small (approx. 100 lines) so maintaining and doing updates can be painful as unexpected bugs or behaviour changes can appear.

    How do you all deal with test driven development within the kaseya platform?

    Ideally I would like to write a large set of unit tests that can mock monitor set alerts, generate emails and make sure the procedures work as intedned on demand to make sure our updates don't break any legacy setups.

    Thanks.

  • MAJOR pain point! We deliver over 380 Agent Procedures as part of our RMM Suite solution. Going from Dev to QA to all the Production sites is way more difficult than it needs to be. I've had conversations about the need for in-place updating of objects (procedures, views, and policies) with the senior engineering and product team members in the past few months, and I'll bring it up again at the next CSC meeting. Right now, any major update is a forklift upgrade - remove everything and replace with the new release.

    We moved to external, compiled applications a few years ago for most of our sophisticated tasks, including daily Endpoint Maintenance and Smart Monitoring. Kaseya now just "tickles" the agent to start the process, and our tools reach out to our cloud distribution server to get the latest versions. Everything is self-updating, right down to the system service that performs ticket processing between VSA and pretty much any PSA. That's been a tremendous advantage over agent procedure based tasks and keeping them up to date.

    As for testing responses to alerts, I have a tool that I wrote that reads a table of our alert codes. From that, it can inject select codes into the event log, stop services (even by terminating the service process) to test our automated recovery methods. We can also generate emails to simulate the OOB device alerts from network gear and make sure that our Intelligent Ticket Processing engine drops, de-dupes, escalates, responds, and/or delivers the alert to the PSA. That took more time to develop and perfect than some of the tools themselves.

    Our largest Agent Procedure used to be around 860 lines long, but since switching to externalized tools for most logic, a "large" procedure is now around 65 lines, and typically now less than 15 lines (including comments.

    Glenn