Test automation with OctoPerf's API
Even though automation is not always the best solution, you can still use some to save time on your day to day chores. And since OctoPerf is a GUI based tool we sometimes get remarks on how "unpractical" or "not devops friendly" this can be. Although I do not agree and still think that even a devops has better things to do than learning another coding language to test his code, I'd like to prove that even a GUI driven tool can be used to automate your testing.
So how does it works¶
And there's a simple reason for that, our backend is made of REST services. So anything that can be done through the GUI can be achieved with REST calls. That does not necessarily means that the work of our front end engineers is useless (they don't take criticism well so let's skip it) but rather that anything you need to do is possible. For today I'd like to automate a simple case to show you: updating the list of users and running a test. This is something you might want to do as part of your continuous integration pipeline, and making sure the list of users is up to date is definitely a plus when it comes to avoiding/analyzing errors. You can find the swagger of our REST api in the documentation or directly here:
We'll be looking at two sections in particular : "Design - Projects - Files" and "Runtime - Scenarios". But first let's find out how to authenticate to the API.
Where to get my api key¶
You can get it from the interface:
Now to use it, you must add a header to every call to the api:
Authorization:500fa2ea-4599-4643-8583-3a5922d0ca65
As I said since our front end calls this very same API you can also get your key by capturing the traffic with dev tools of your browser. It is a good way to reverse engineer the API, but since there is a documentation you should not need it.
Upload a new file to the project¶
First you must know that uploading an identical file to a project will overwrite the previous one. With this in mind we know uploading the new file to our project will be enough to update it. Now look at the "Design - Projects - Files" section of the API and more specifically the "Upload file inside folder with ID" POST. The main parameter we need is the projectId, but this is easy to get since it's displayed in the URL when you are on this project in the GUI:
With this in mind we can prepare our POST:
curl -X POST --header 'Content-Type: multipart/form-data' --header 'Authorization:500fa2ea-4599-4643-8583-3a5922d0ca65' -F file=@Credentials.csv 'https://api.octoperf.com/design/project-files/AV1kfu3A3lJQphsGapLU'
And run it:
Of course I must have the csv file in the same folder or enter its fully qualified path. Now feel free to go back to the design screen and look in the file section, or check the list of values from the variable menu to see it's been updated.
Running a test¶
Now to run a test, first I'd recommend you use the GUI to configure it. As there are many options, I find it easier this way. I'll try to cover the scenario design with the API in another blog post.
When it is configured, you can get its Id from the URL once again:
Which leads us to the following API call to launch the test:
curl -X POST --header 'Content-Type: application/json' --header 'Authorization:500fa2ea-4599-4643-8583-3a5922d0ca65' 'https://api.octoperf.com/runtime/scenarios/run/AV1kj8pcsYyCovImG8Pt'
This will create a new benchResult based on this scenario, and in the response you get details about it:
This response is useful if you plan on waiting for the test to end to gather results or just use the API to get live metrics. In any case it will also be available from the interface:
Conclusion¶
I hope this quick post demonstrated that OctoPerf is flexible enough to fit even in devops environments. But I should mention that whatever you want to do through the API, it might make sense for us to do in the interface. So please share your ideas with us and allow us to make testing easier for you too!