1

I am implementing automated tests of the system that consists of many microservices.

To verify appropriate behaviour of the endpoints using POST and PUT methods, I need to obtain some data (for example IDs) and set body or request headers using them.

I can obtain such data by: - calling appropriate endpoints using GET method, - obtaining IDs directly from the database.

Which of the mentioned ways is the most appropriate / the best practice? When I call GET to obtain data, I test also whether this endpoint works properly. On the other hand it is for sure slower than checking value directly in the DB.

2 Answers 2

4

This depends on what type of testing you implement:

  • If it is a component testing (or if your goal is to test the particular end-point) you should isolate your component from the possible impact of other components. So having no options to mock the data I would use direct database access.

  • If it is an integration testing then I would use endpoints to obtains the data. Despite the components might not interact directly you will anyway catch defects which might be caused by inconsistency between the provider and the consumer.

2
  • That's was my initial thought as well. However if GET endpoint fails, this will mark whole test case as failed. While it is obviously okay to know that something is wrong, what if my purpose on particular test case is checking whether it is possible to POST.
    – matandked
    Commented Dec 21, 2018 at 11:54
  • Looks I misunderstood you question. I thought that GET is a method of one microservice and POST is the method of another microservice. If they are both related to the same microservice, then you sure can ignore GET endpoint and just fetch the required data straight from database. Updated my answer accordingly.
    – Alexey R.
    Commented Dec 21, 2018 at 11:56
0

I think it depends on what is being tested and what is being used as means for this testing.

So for example if I just need the IDs as test data for further API testing then I use what is fastest (which is DB).

I also follow one simple rule in testing:

One thing at a time.

I make sure I am not trying to test multiple things in a single test as I think one test should Pass/fail for one reason only for which it has been designed.If A test can fail for multiple reasons then it is confusing and analysis of it will take longer time.

Keep it simple.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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