If you are looking for the full API documentation, click here

There are a few ways to run automation with PractiTest. You can read about them here.

PractiTest supports the execution of both Manual and Automated Tests, allowing customers to run tests from any commercial or home-grown tools.

PractiTest’s API lets you integrate your automated tool with PractiTest.

The Automation API enables you to notify PractiTest automatically with your automated testing results.

You can run your automation using any automated solution (such as Selenium, Ranorex, etc.; or CI platforms like Jenkins, CirlcleCI, etc.) and update PractiTest directly using the Automation API.

This way, you get a clear picture of the testing (manual and automated) within PractiTest.

Make use of PractiTest’s API in order to generate the automation you need.

  • Integrate all the test runs (manual and automatic) in your project under one roof.
  • Flexible – define the functions you want.
  • Can be run automatically -> whether via a cron task or when you commit, depending on your needs and configuration.
  • Integrates with your existing framework.
  • Define the results you want for your report - Generate reports and dashboards for all your testing types in one place.
  • Initialize your automated tests (via framework) and update PractiTest with your results.
  • Support all different test statuses: PASSED, FAILED, BLOCKED, NOT COMPLETED, NO RUN.
  • Supports steps inside runs
  • Works everywhere in every language, just update us with a simple POST command.
  • CONS: your code needs to update PractiTest in your code.

API Tokens

In order to work with API, you will need to generate an API token.

PractiTest supports two types of API Tokens: Personal API Tokens (PAT) and Account API tokens. We recommend users use PAT in order to ensure security and for better enforcement of user permissions. To learn more about the differences between Personal and Account API tokens in the API Documentation please click here.

Personal API Tokens (PAT)

The personal API token is a unique token given to a specific user.

There are two kinds of API Tokens:

  • PAT with User’s permissions - This option means the PAT permissions will be according to the User’s permissions. When Using this PAT, the user CANNOT use the Author ID at all in his command - The Author of Tests and Test Sets will be the ‘User’
  • Personal API TOKEN with user impersonation - This option means the PAT permissions will not be restricted to the user’s permissions, and the user will have all the account permissions. The user can either user Author ID or not. If the User uses Author ID, the Tests and Test Sets’s author will be according to the author ID value. If the user doesn’t use Author ID, the Tests and Test Sets will have the user as the Author.

PAT should be kept private, like any other credentials. In case a user has more than one account - he will have a different Personal API Token for each account.

To get a personal API Token, the account owner must enable it for the user through his account settings window as described in the User Management page.

Once the Personal API token is enabled for a user, he can find it in his user settings personal tab, as described on the Personal Settings.

Account API Tokens

API tokens grant access to read, create, update, and delete data in PractiTest. Account API tokens grant this access to all the projects of your account.

When using Account API Token, you have to use the Author ID.

It should be kept private, like any other credentials, but stronger since it controls all your accounts.

Only Account Administrator can see the API Token screen through the Account Settings.

What Is The API Token Name For?

Api Tokens have names so you can remember to who / what you gave access via the API tokens.

API Tokens that start with an underscore are reserved for specific use / specific integration. Don’t use them unless it’s for a specific reason (followed by our instructions).

api-token

Best Practice Using Account Tokens

In case you choose to work with account tokens although we recommend using PAT when possible, here are a few best practice tips.

Since you can create as many api_tokens as needed, rename them, disable and enable them, it is a best practice to give different api_tokens to different (code) purposes/business needs. Once you may have different business needs, or you’ll need to disable one of the functionality, it will be easier for you to just disable one API_Token at a time

Security

Your API Tokens should be kept private, like any other credentials:

  • When possible, use Personal API Tokens and not Account API tokens to restrict access to your data according to specific users and tasks.
  • Never send your API Token via an email
  • If you’re writing a script or program that accesses the API, do not pass the token in cleartext (use HTTPS exclusively)
  • Do not embed your token with your code if that code is visible to others. This is especially important with JavaScript since JavaScript code is visible to anyone that has access to the page it’s running on.
  • Give specific API usage different API Tokens with an explicit name.
  • If you suspect that your API token has been compromised, or you’re not sure for what reason it is used – Delete, disable, or regenerate it.

PractiTest’s API Documentation

Find all the necessary documentation and explanation to PractiTest REST API here

How To Use API For Automation - Step By Step Guide

Download the full step-by-step guide for integrating PractiTest with automation frameforks here.

The main API method to choose is: “create_a_run”.

  1. Create equivalents of your automated tests in PractiTest. Under test type choose automation - API. You can use this POST request for this process.
  2. Group the equivalent test cases into Test Sets, this request allows to do that. Please make sure to use the ‘data/instances/test-ids’ parameter hence Test Sets will be created with relevant tests inside.
  3. Once an automated test is executed, you will need to send this POST request that uploads its result into PractiTest.
  4. The POST request above has a mandatory parameter called ‘data/attributes/instance-id’ and the instance-id can be retrieved by using this GET request where you can use the ‘name_exact’ and the ‘set-ids’ parameters. That’s why we recommend using the same name convention for your equivalents. Note: Only system IDs can be used when using the REST API.
  5. Once you have a new version of your product, you can clone the original Test Set by using this request and send the results there.

See a full example of how to send the results of your automated test in Selenium to PractiTest here.

To integrate Selenium C# to PractiTest, please use the workflow described here.