Simplicity is the ultimate sophistication Leonardo da Vinci, 1452
Automated, cloud-hosted testing for API and microservices, in a low-code environment!
Step 1 is to create a project and quickly define some tests. Here's a simple service test:
$send snakk.json (url="https://specs.dieselapps.com/diesel/mock/getAccount/45")
$expect (payload.someStats is "456")
Note: snakk.json
will call a REST API and process a JSON response. Other flavors are available, like snakk.text
or snakk.xml
.
This is a simple test, getting a JSON document from a REST API and testing the contents of it.
Now, to run this test automatically, we have to configure a polling schedule and a deployment detector.
Here's the **polling schedule**:
$when diesel.realm.loaded
=> diesel.guardian.schedule (env="sandbox", schedule="5 minutes")
These tests run continuously and make it very easy to catch when the actual service implementation diverges from the original requirements...
The deployment detector will detect when new builds are being deployed in an environment:
And here's how we're polling (the **deployment detector**): the page should return a different content every time the server has been updated:
$when diesel.guardian.poll(env)
=> diesel.setEnv(env, user=diesel.username)
=> snakk.text (url="https://specs.dieselapps.com/admin/ping/shouldReload")
=> diesel.guardian.polled(env, stamp="specs-"+payload)
This will catch new deployments and run the test suites (stories)...
The last piece of the puzzle is configuring the notifications: what to do when the tests start failing or come back to stable:
$when diesel.guardian.notify (realm, env, oldStatus, newStatus, errors, total, report)
=> diesel.mail.send (
to="me@co.com",
subject = "${errors} / ${total} Guardian errors in "+env + " (" + realm + ")",
body=report)
If it looks like overkill to write rules to send emails, it's because the rules engine we use can be configured to do a lot more things ;).
Used by companies like...