How to implement integration testing for IdentityServer4?

user_1616049 0
Viewed 2138

This is more of a general question not a specific one, but I hope it might help someone in the future with the similar problem.

I am implementing IdentityServer4 for my business case where I initially want to set up authentication and authorization for a public API access. For that I will be initially using only ClientCredentials flow. For manually testing the usage flow and correct configuration and setup, I have created a small test API and a Client console app as in the sample projects from the documentation. But I want to automate it as I have almost completed the IdentityServer4 setup and am going to start working on the actual API itself.

So basically I want to do some integration testing against my implementation of the IdentityServer. But I have minimal experience regarding this topic so maybe you would have some suggestions or tips on how to set it up.

Should I set it up on the API side, when at least some endpoints are already done? But if my IdentityServer and the API are in different solutions, then for example for running these tests locally, I would still have to start IdentityServer manually and then could run the tests on the API project which connect against it?

Or for me it would make more sense to have the tests, the test api and client in the IdentityServer project (much in the same way it is done in the source code solution). But when looking at the source code integration tests, I saw they had a separate Startup class for IdentityServer startup. Should I do this similarly or rather configure the tests to run against the Startup class of my own IdentityServer project? Then I would have to copy all the appSettings files etc.

I know it's quite a general question and topic, but any pointers will be appreciated on how to actually test the correct thing. I know I don't need to test a lot about the functionality itself as it's also done in the source code solution, but I would rather have the integration tests for testing my own configuration etc, so if any of the components fail to communicate to each other, I would know immediately.

Thanks in advance!

asp.net-core-2.0 identityserver4 asp.net-core integration-testing testing
1 Answers

I mostly agree with your thoughts.

I had asked a question here on StackOverflow before I started my IdentitySerever project. That was answered by @Lutando, and four users upvoted this (though no one like :( the question). Anyway, we have added few acceptance and integration tests for our project. You can check this thread to find out some details about how to write this kind of test

Or for me it would make more sense to have the tests, the test api and client in the IdentityServer project (much in the same way it is done in the source code solution). But when looking at the source code integration tests, I saw they had a separate Startup class for IdentityServer startup. Should I do this similarly or rather configure the tests to run against the Startup class of my own IdentityServer project?

I can tell how we proceed on this in our company (Not everyone like the idea). As our identityserver will deal only with Hybrid Flow (to authorize only mvc app, win app and rest api), we created some example projects (each for one kind) and run them through the TestsServer. We have some virtual methods on Startup class of IdentityServer so that we can seed data and connect to memory databases. Each test creates its own database in memory

Anyway, these tests have done their jobs very gracefully. It tooks 7 moths to finish implementing the IdentityServer with Admin Interfaces, and many times pointed us to the wrong implementation. These tests are usually worth the effort

Finally, I want to point out few things I have found while developing IdS4

  • Integration tests are taking long time, so not to duplicate same kind of tests.
  • As you mentioned in your question, IdentityServer4 source have already tests their code properly, so no need to tests how the identityServer4 is working. Just test the succeesful connection part.
  • It is hard to test the assert with access_token or identityToken
  • Use browser client to work with redirection and cookies
  • Finally, it is difficult and time consuming to write integration tests in this way. I believe that we should just add enough test for basic functionality of interactions between the projects

However, if you are familier with Selenium/Coded UI or similar tools, better to write integration tests using those. I believe, writing few acceptance tests (or Service level tests) just to confirm that new code does not break the workflow is better approach

Finally, I would like to add some of our acceptance tests, that we found save our times

  1. Login from MVC client
  2. Login from a client and call a api from mvc client
  3. Consent Page appears or do not appear based on settings
  4. Call API from a console app
  5. Api Call fails because of insufficient scopes
  6. User claims added successfully ...

and number of integration tests we have is 22

Feel free to correct me if anything I mention here is not a right approach.

Best of luck with your IdentityServer4 implementation

user_35010520
Related