Handling authorization when testing against API about nodejs-integration-tests-best-practices HOT 5 CLOSED

• What about testing against real envs with the same suite? IMO the tests should be able to mingle between envs easily. (also for CI/CD)
• In the case your service is behind a3rd party gateway service, you can mock the header.

from nodejs-integration-tests-best-practices.

What about testing against real envs with the same suite? IMO the tests should be able to mingle between envs easily. (also for CI/CD)

That's a great feature 🔥🚀 which is not necessarily related to auth. I guess it's feasible for some of the tests (black-box tests) as those who are utilizing test doubles or alter the config (grey-box tests) won't be able to run against remote env. How can we separate between the two? Probably need to tag the black-box tests + make the URL inference dynamic, not always work against localhost rather make this configurable. I would also add this to our features list in the home page.

In the case your service is behind a3rd party gateway service, you can mock the header.

Not sure I followed, could you clarify?

from nodejs-integration-tests-best-practices.

@goldbergyoni For example, if you use Apigee, the authorization step happens before the request get to the service, so you can just send a mocked Authorization header

from nodejs-integration-tests-best-practices.

@mikicho What is a mocked auth header? I guess you refer to API gateways which accept a valid token

I'm asking to ensure I don't miss a bit

from nodejs-integration-tests-best-practices.

@goldbergyoni mocked auth header is jwt for example. If you sever doesn't verify it (because this is happening before the request hit your sever) you can send whatever value you want

from nodejs-integration-tests-best-practices.