2

I've manage to get new job and what I can say so far - expectations for me are high. I never used to test API on production - usually I've been teached to test API on dev/test enviroment, but in currect job they got only production env.

My task now is to write requests with Postman, so I have prepared the Workspace, collection and folders and now I should start writing requests. My question is to more experienced guys - should I avoid testing DELETE, PATCH, PUT request and focus only on POST/GET requests because of production?

2
  • Your question is very contextual, it will all depend on what type of operations you want to do and its consequences. The actual HTTP request type (implementation detail) is less important than what actually happens on your system (use cases). The question "If I do X, what can happen?" - and if the people you are serving say "That's fine, go ahead", you go; if they say "That's not fine, but we still need to test it", then you bring the this testability problem you have. – João Farias Dec 7 '20 at 16:05
  • I would suggest re-writing your question, focusing on use cases, so people with experience in the domain can suggest different approaches. – João Farias Dec 7 '20 at 16:05
2

The answer depends on many other factors including the infrastructure.

  1. Even POST requests can create unwanted changes in production DB so GET is mostly the only safe method, investigate if this is the case for your product.
  2. Do you have a staging server where you do rest of the use cases (if you plan to use only POST and GET in production)
  3. What is your team decision and what are their expectation
  4. What is the product structure, is there test sandbox that you can access from the production environment so that you won't affect real users
  5. What kind of product are you testing

So as in any test activity, the answer is:

  1. The approach is context depended
  2. You should have proper risk analysis on what happens if you don't test other http methods and stick to only http GET and POST
  3. Is there a backup or restore option if something goes wrong.

Sometimes you won't be able to get answers for all those questions due to immature project stakeholders and process. In that case, I would stick to the below procedures:

  1. Ensure to test all GET actions and validate the response schema
  2. Check authentication and authorization test for test users. Make sure your test accounts have limited authorization and the test accounts have access only to test data. Don't test admin account use cases as it can cause unwanted changes
  3. Don't use admin test accounts as account breaches can compromise the entire production environment
  4. Check production environment response time
  5. Run postman monitor to ensure health of the production API
  6. Stay away from CRUD operations other than R (Read, means GET)
  7. Discuss with the team on other use cases and be clear on the risk involved
3
  • thanks @PDHide! – nieudacznik toja Dec 7 '20 at 15:23
  • Could you accept the answer – PDHide Dec 15 '20 at 1:26
  • You can accept the answer by clicking the tick sign near to the answer – PDHide Dec 15 '20 at 1:26
0

If you have no other options except of performing your tests in prod, you should avoid using the methods which change the application state. Here are few sides you can look at the issue from:

  1. HTTP standard defines so called "safe methods". They are basically the methods which imply read-only access to the data.
  2. However the above is only the convention. So in your particular case the handlers dedicated for those methods might not follow the standard.
  3. You also should understand there might be different types of testing. For example running performance tests on production is always bad idea no matter which HTTP methods you use and how safe they are.
  4. If your application is designed to perform some limited testing in production you that will might be fine to test even the methods introducing the changes to application state (for example there might be a dedicated realm configured for testing)
  5. Any sort of testing in production has to be performed very carefully. You have to understand what you're going to do exactly and why (e.g. test if hotfix has been properly applied). The testing has to have as narrow scope as possible.
  6. Any sort of testing in production has to be performed only after the discussion with responsible dev lead that might advice what you can do and what you cannot do in every particular case.

Summing up there are two worlds: ideal world where everything is compliant to HTTP standard where you can perform limited testing using "safe" methods and real world where nobody can give you the right answer except of the people how develop the service.

1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.