CODEWITHSUNDEEP
c#testingasp.net-web-apiacceptance-testing
Martin Hansen
Martin Hansen

Reputation: 2101

web api 2 verify controller is running on production environment

I'm fairly new to C# and web api 2 and creating a web service for some internal usage. I have smoke- and acceptance tests setup in my CI pipeline for our development and test environments, these insert bogus data in our DBs, and validate all sorts of output, errors messages and so on.

And here comes the problem; acceptance/configuration testing in our production environment when we have deployed a new release.

Ideally i would like a simple configuration test/report that tells me that controllers have been instantiated correctly, and on the correct route.

Is there a way natively in web api 2 to achieve this? If not, what would you suggest for testing availability of controllers on a production environment without polluting the database (for POST request) and having known data to test upon.

Upvotes: 0

Views: 987

Answers (2)

Gerino
Gerino

Reputation: 1983

I'd probably create a /test endpoint with a GET, that returns a status of application, whatever you need. For example whether it can execute sql (even if there's no data), it could generate links to all known endpoints using UrlHelper (you'd probably have to use either reflection or custom attributes or just provide list of controllers/actions to verify) and display them.

You could create a custom filter attribute that would verify whether specific data is provided in request (like a custom header) and not actually run the action (by setting the response), but return information what action WOULD be executed (using stuff like controllerContext, actionContext or whatever). Then you could either manually or using some automation (even from within the /test endpoint!) make calls with that header and check whether the URLs correspond to correct actions.

Upvotes: 1

Oli Wennell
Oli Wennell

Reputation: 866

I'm not aware of any way of checking the controllers running in production other than doing HTTP requests.

If it was me I would have some way of identifying requests as being "test only", (maybe a custom HTTP request header, or by looking for a special value within the input). Any data written to the database as part of these requests would be flagged as "test only" to make it distinguishable from "real" production data.

Alternatively if your main concern is just the controllers and you don't get enough confidence from calling them in a test environment, then maybe add a diagnostic route to each one and call that. E.g. "controller1/test" returns 200/OK to show that controller1 is configured.

Upvotes: 0

Related Questions