AppDoctor tests are one of the main tools that enable companies to provide proactive support. When you are able to see the issues in your system before you users do that is always a good thing.
AppDoctor tests provide unlimited possibilities in how you monitor your application. You can think of AppDoctor tests just like you think of your integration tests that run locally or in your CI/CD. By being able to test your application while running in production you are able to monitor degradation and fix it the minute it happens. Maybe something slips through your tests while deploying and breaks something in production. This is something you should instantly know about and be able to fix. Maybe you have an unrealistic deadline and won’t be able to write tests, with how quickly you can set up AppDoctor tests you are still covered.
An example of a small AppDoctor test might be the following:
- Register new user
- Login as user
- Post comment as user
- Delete comment as user
- Delete user
With the power of AppDoctor Assertions you can get as complex as needed each step of the way. You can test stuff such as things returning quickly enough from a specific region or the response body containing the correct data. Truly anything is possible with AppDoctor Assertions. If you find yourself lacking power you can even write Lua assertions instead.
Setting up a test allows you to change multiple settings such as if it should retry, how long after fail should it retry, how often a test should run (every x minutes) and what regions it should run from. There are many options to have your tests run exactly like you need.
Test Step Types:
With 6 different test step types you can have as complex of a test as you need.
Request is the bread and butter of AppDoctor tests. With requests you can test any url you want in any way you want. You can set variables from the response of the request so that they can be used later in your test pipeline. An example of this is login returning a token and you later use that token in the header of all your test requests. You can set Assertions for anything from response time to checking for existing header values.
With sleep you are able to pause your test for X amount of seconds.
With subtest you are able to run another test inside your current test. With this level of customization you can organize your tests how ever you like.
Conditional step allow you to do all sorts of cool things. By allowing you to run X steps only if X assertion happens you can reach a wide level of customized tests!
With step add variable at any point you can inject new data into your test that can be used down your test pipeline.
With step End-if you can short circuit a test and stop it based on complex assertions. One example may be if a specific test fails then end the entire test.
As you can see above, the amount of customization in tests allows you to truly replicate your integration tests while having them run periodically against your production environment. We are super excited to finish the UI around tests and get it into beta users hands!
Follow us on twitter to learn more about our development and receive future discounts for being along for the ride.
If you are interested in joining our closed beta, shoot us an email at firstname.lastname@example.org
Until next time. ✌️