How should I assert in WebAPI integration test?

Question

I'm writing integration tests for Controller classes in my .NET Core WebAPI, and honestly, I'm not sure if Assert.Equal(HttpStatusCode.OK, response.StatusCode); is enough. I'm using my production Startup class with only database different (using InMemory database).

This is one of my tests, named ShouldAddUpdateAndDeleteUser . It's basically:

1. Send POST request with specific input.
2. Assert If POST worked. Because POST sends respond with created object, I can Assert on every property and if the Id is greater then 0.
3. Change the output a little bit and send Update request
4. Send GET request and assert if update worked.
5. Send DELETE request
6. Send GET request and assert if null.

Basically, I test, ADD , UPDATE , DELETE , GET (when item exists), GET (when item doesn't exists).

I have a few questions:

1. Is it a good practice to have such tests? It does do a lot, but it's not a unit test after all. If it fails, I can be pretty specific and specify which part didn't work. Worst case scenario I can debug it pretty quickly.
2. Is it integration tests or functional test or neither?
3. If this is wrong, how can I test DELETE or UPDATE ? I'm kinda forced to call GET request after them (They return NoContent )

(Side note: It's not the only test I have for that controller obviously. I also have tests for GET all as well as BedRequest requests)

Answer 1

Is it a good practice to have such tests? It does do a lot, but it's not a unit test after all. If it fails, I can be pretty specific and specify which part didn't work. Worst case scenario I can debug it pretty quickly.

Testing your endpoints full stack does have value but make sure to keep in mind the testing pyramid . Its valuable to have a small number of full stack integration to validate the most important pathways/use cases in your application. Having too many however, can add a lot of extra time to your test runs which could impact release times if those tests are tied to releasing (which they should be).

Is it integration tests or functional test or neither?

Without seeing more of the code I would guess it's probably a bit of both. Functionally, you want to test the output of the endpoints and it seems as though you're testing some level of component integration if you're mocking out data in memory.

If this is wrong, how can I test DELETE or UPDATE? I'm kinda forced to call GET request after them (They return NoContent)

Like I said earlier, a few full stack tests are fine in my opinion as long as they provide value for major workflows in your application. I would suggest one to two integration tests that make database calls that make sure your application can stand up full stack but not bundle that requirement for your functional testing. In my experience you get way more value from modular component testing and a couple end to end functional tests.

I think the test flow you mentioned makes sense. I've done similar patterns throughout my services at work. Sometimes you can't realistically test one component without testing another like your example about getting after a delete.