Having C# API automation tests running during deployment

Question

Hi,

I recently moved to a project which is having C# APIs. CI/CD pipeline has been setup for continuous deployment. The project is almost build from past 5+yrs. The project has a set of API automation tests configured in CI/CD pipeline which will be executed during deployment to validate whether all the APIs are working. If any test fails, API won't get deployed.

Design and content of API automation test:

• C# test project using Microsoft Unit testing.
• Uses REST client to call APIs for testing.
• For each API (GET/POST/PUT/DELETE) a separate test method has been written which will call the actual API using REST client.
• The test will call actual API and does database operations (CRUD) which delays execution of test process which in-turn delays deployment.

Doubt:

• Is it a good practice / approach to have API tests which is performing CRUD operations by calling each and every API during deployment into various environments?
• We have Unit tests for each API where we use MOQ. Unit tests will be executed when we raise PR (pull request) for merging to master. And also we have minimal required integration tests. So, do we need to have a separate API test (that does CRUD operation) during deployment?

We are trying to have best practices in place to avoid blockages / overloading tests during deployment.

Please suggest if there are any best practices related to having different types of tests for C# API projects.

Thanks!!! in advance...

Answer 1

You could always abstract the actual persistance either by mocking (you mentioned the excellent Moq) or by providing your unit tests with an in-memory database. That way, the tests will be quick to set up, execute and tear down. After all, it is the application logic that you are seeking to test, not the actual persistance technology.

Answer 2

If your requirement is regression testing via automation, you must keep the automation tests in your pipeline which will help save manual testing efforts esp. in Non-Prod. If there is any issue you can roll back, assuming you are using blue-green deployment. For production, you need to avoid automating any CURD optimizations unless you have some test accounts that are authorized by the business users you use and test them.

If your requirement is to check if the application is up and running after deployment, you can simply call the health status of the deployed application in your pipeline. If the health status is Ok, you can swap the stages, and roll back if there is any issue.