Working with Projects

• ReadyAPI preferences
• Locally-stored properties
• Global and system properties

You specify the project file and format when you are saving your project for the first time. You can see the project file name then in the project properties:

Click the image to enlarge it.

As we said above, a ReadyAPI project can be a file or a set of files. It depends on whether the project is composite or not:

• Non-composite (regular) projects consist of a single file. This format is considered legacy and can be useful when only one person works on the project at a time.

• Composite projects consist of several files, each of which includes information about individual project items (test case, load test, and others). This project format is source-control-friendly. We recommend using it when you need several persons working on the same project at the same time. To learn more, see Teamwork.

As you can see, every project in ReadyAPI’s Navigator panel has a few predefined nodes: APIs, Functional tests, Performance tests, Security tests, and APIs (Virtual). Each of these controls the corresponding project items:

• APIs – Contains the API definitions added to the project. These definitions can have different formats (OpenAPI, Kafka, GraphQL, and so on). The internal structure of an API definition depends on its type. A REST service definition, for example, includes a hierarchy of resources and methods, while a Kafka service is a set of channels with the publish and subscribe operations.

  The APIs node helps you see available resources and operations, and to try how these operations work, you can configure parameters, send requests, and explore responses. ReadyAPI treats the settings you made to requests in this section as request templates for functional API tests.

• Functional Tests – Contains functional API test cases. For convenience, they are organized into test suites. Each test case is a set of test steps simulating requests and other operations. In other words, a test case simulates real usage of the tested service and corresponds to some user workflow (or user procedure). Test suites include multiple user procedures. They may or may not relate to the same feature of the tested API.

• Security Tests – A collection of security tests. Each of these tests performs a number of security scans that simulate hacking attacks against the service. The tests check that the service doesn’t expose valuable information.

• Performance Tests – Contains load tests. They help you check how your service behaves when many users (dozens, hundreds and even thousands) are sending requests concurrently.

• APIs (Virtual) – Contains virtual services that mock real APIs.