this is a followup question to the following StackExchange question -

If you had a medium size company, several developers - but zero tests written in your REST API's - where would you start?

At the time our applications were started, Microsoft provided OAuth2, but the nodejs interface wasn't exactly complete. So we built our own to interact with their JSON API. We haven't had any issues with this. However ... there are no tests written on our end. To write tests I have to either Mock a Microsoft token or I have to figure out a way to programmatically obtain a real Microsoft OAuth token.

  • OAuth begins by hitting an API endpoint, generating a callback code, and forwarding a user to Microsofts login page where the user will enter an email, password and a 2 step authentication
  • On success, Microsoft will redirect the user with a valid callback "code" to the original API, where the API receives the callback code from Microsoft and under the hood reaches out to Microsoft to obtain the users details from this provided code.
  • On success, a valid token is returned to the user, and under the hood the refresh details are stored for later use when the token expires.
  • the user can then use the token they have been given to make all subsequent requests to API endpoints

this is my understanding of how it works, but whether or not this is correct OAuth implementation thats secondary -

How can I mock a login to Microsoft in order to fire all of my HTTP tests against my apps? Do other developers build a back door for testing endpoints when interracting with OAuth? It almost sounds like I have to write a small web-scraper to get a valid token, but that doesn't seem proper.

  • Do tokens expire? Can you generate tokens at will from any MS web console? On the other hand, after you got the token, what do you do with it? Does it bear any information required by the API? Is it formatted as JWT?
    – Laiv
    Aug 6, 2021 at 13:08
  • If you can log in with a mock token you've done something wrong! Aug 8, 2021 at 9:28

2 Answers 2


Basically, any external service must be faked in your tests. The reasons are many, but most importantly:

  • a fake guarantees speed.
  • fakes make it easier to write and maintain the tests.
  • you dont need to test that the external service works. it is safe to assume it has its own tests.

So write a fake that when called returns the same data as the real service, and use that for testing. Ideally you would create an Interface before, and then have a Service Provider to give your app an instance of the real Service or the Fake, depending on the environment.

If your goal is to test the actual service you will have to set up a real Integration test, but this is really complex and should be handled separately from the main set of tests your developers execute on a daily basis.


Assuming your provider implements a standard OAuth2 service, you can simply spin up your own in your test/dev env and point your API/Website at that.

Given that the only think you will need to change in the issued token is the expiry date its conceivable that you could completely mock this with something like mountebank

A quick google find one online that you can point at https://www.mocklab.io/docs/oauth2-mock/ although I would be wary of using this for a commercial operation.

OR https://www.npmjs.com/package/oauth2-mock-server

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.