Different test validations for environments

Different test validations for environments


Most probably, your staging and production APIs respond to most requests with 200 OK. Having a shared set of validations between multiple environments is handy as you can set 200 OK once and have it validated against all of environments. What about response time? Does your staging API respond to login requests as fast as your production API does? Probably not and that’s OK because for test environment, the response time is not that important. How would you set the “Response Time” validation for a scenario like this? Up until today, there wasn’t an easy way to set these kind of validations but that’s not the case anymore.

Apart from shared validations, Testfully also allows you to define a set of validations specific to an environment. Moreover, you can mix and match both features together and have a set of validations (for example, Response Code) shared between all environments and have Response Time per environment.

How It Works

The Validations tab in Test Editor continues to be the place to set validations. We have updated this section so that it accepts a set of validations for all environments and a set per environment that is added to your workspace. Click on the environment names to expand and collapse the validations form for that environment.

Set validations per environment in Testfully

We’re very excited to see how this feature improves your development workflow and would love to hear what you think about this feature. Also, we have put together some FAQs for you and highly recommend to go through them, it won’t take much of your time.


What’s going to happen to my existing test cases?
Your existing test cases will continue to work as you expect. The validations appear under the “All Environments” section.

Do I need to set validations for all environments?
No! You can choose to set validation for one environment and leave the rest empty.

What would happen if I set a common Response Time validation of 200 milliseconds and 250 milliseconds for my staging API?
When running your test agsinst staging API, Testfully takes the 250 milliseconds as that’s what you have set explicitly for the staging API. For any other environment you might have (for example, Production), Testfully will use 200 milliseconds as the expected Response Time.

What would happen if I set shared Response Body and a Response Body for my production API?
When it’s time to validate Response Body of your test against the production API, Testfully will merge the expected “Response Body” for Production API into the shared Response Body and uses the result as the expected response body. This is also same for Response Headers.

Recent Articles

Top 7 Free & Paid mock API tools (2022 Review)

Sometimes called a fake API, A Mock API is when you build an API that returns the desired data. Still, it is not your actual API, and it all has been simulated for some use cases. This article covers best free & paid mock API tools in the market.

Top 10 GraphQL clients

GraphQL is one of the hottest topics in the API development world, and that’s for good reasons: GraphQL APIs address many of the issues that we had with Restful and SOAP APIs. This article goes through the Top 10 GraphQL clients you can use today to develop and use GraphQL API.

Why your Website is giving an HTTP 405 Method Not Allowed message and how to fix it

When a response has the status code 405, the client attempted to access a resource using an HTTP method that is not permitted by the server for that resource. Websites, Restful APIs, and web applications tend to return this error. This article provides a more detailed explanation of this status code’s meaning and how to handle it in your applications.