5

I have a scenario where I need to set up integration testing against our microservice architected application. This will mean creating some tests using Postman to hit our API, and running them with Newman. We also use oAuth with Identity Server, so we need to initially authenticate, then receive a token back which is passed into all of the requests.

The problem is when we make the initial call to authenticate the user, how do we know that the user exists in the environment that we are running the tests?

2 possible solutions that I can think of are:

  • In the test script, create the User at the beginning (and possibly delete them again at the end). This would be problematic for us because that part of the API is not public (we don't want external users to be able to create new users)
  • Deploy a dummy identity service that will return an authenticated token. This doesn't feel like it would be a proper integration test for me.

I was wondering how others would approach this sort of problem?

Improve this question
3
  • 1
    Why don't you set up the test user in your test env so that you will 100% sure the user exists and you will be using that user for all your tests?
    – Alexey R.
    Oct 12, 2017 at 10:16
  • What is it that you are trying to test? Your service or the Identity server? If it is the first, mocking the identity seems a valid solution to me. I don't fully get the problem with creating users and it being private? What is it that you want to prevent? Are the Postman scripts being made available to outside parties?? If the Identity is under full control of your company, why not extract users first that you know exist for instance?
    – Ray Oei
    Oct 12, 2017 at 16:00
  • Hmmm, perhaps you are right and I have overthought this. The simplest solution might be to always have the user created upfront. Thanks
    – jazza1000
    Oct 13, 2017 at 6:32

1 Answer 1

Reset to default
1

A possible approach to handle authentication in API integration testing is to use a test/dummy user with known credentials, that is exclusively created for testing purposes and does not affect the production environment.

To make sure the test user exists, you can set up a fixture that creates the user in the database at the beginning of each test run, and deletes it at the end. This way, you don't have to worry about the user creation API being public.

As for the dummy identity service, it can be an option if the identity server logic is complex and affects the test results. However, it's not ideal for true integration testing as it bypasses the actual authentication process.

Another option is to use a mock identity server that returns a predetermined token for the test user. This mock server can be set up specifically for testing and can emulate the behavior of the actual identity server without affecting it.

In summary, the approach to choose depends on the specifics of the API and identity server, but creating a test user and using a mock identity server are two possible solutions.

Improve this answer

Your Answer

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

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