Home/ Questions/Q 3968260
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T03:49:15+00:00

I have a REST web-service interface that calls-down to a service layer which orchestrates

  • 0

I have a REST web-service interface that calls-down to a service layer which orchestrates the creation, deletion, etc. of various objects in an entity-layer. These entity-layer objects ultimately map to database records. I have a number of unit tests (in nunit, it a c# application) that test this interface by sending http requests.

Consider my testing of a web service request that creates a some entity-layer object. I obviously want to verify that the web service considers the request to have been processed correctly, by checking the http status that it returns to me plus some data in the response body. I also want to independently verify that the correct database records have been created. I have a couple of ways (that I can think of) to do this:

  • The easiest way is to use existing ‘reader’ classes in the entity layer to read and validate the database entries. This is easy because they incorporate the validation and consistency logic for the entities they deal with, and using them is simple. I am uneasy about this, though, because I would be using the code I’m testing as part of the test. This seems to violate some principle of separation of concerns, and also introduce the possibility of an entity-layer bug causing the object creation to fail but appear to the unit test to have succeeded.

  • Alternatively, the test code could go straight to the database and do the checks itself. But then I’m embedding details about object storage and consistency rules in the test – which makes the test brittle if those details change, and also effectively means re-implementing, in the unit tests, the code I’ve already written in the entity layer.

I wonder what people think of the trade-offs involved with these (and maybe other) options, and what (if any) is the best practice? I’m not sure if there is a right or wrong answer, but I’ve wondered about it for a while and interested in other opinions.

EDIT

To clarify, I save separate test suites for the service-layer and the entity-layer. The concerns I have expressed — using tested code in a test — also apply to these tests.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    We see two different tests, a test of the service methods and a test of the webclient.

    For testing the service methods (like a reader), you may want to create a database with predefined values (test data), call the reader, and test, if the readers output matches the test data in the required way.

    Once you’ve tested the service methods, you can move to the next test level and test the web client, again using the same test data but now testing if data shown on the web client matches the test data in the required way. On this test level, you can “trust” the readers (because they have been tested before).

    Maybe you feel more comforable if you separate between “unit testing” and “integration testing”. For unit testing, verify that a compilation unit works as required. This could be testing the reader: you populate the database with defined data, call findAll() (or something else), and assert that the test data and only the test data is in the result.

    The other test is an integration test – there you verify, that service layer and entity layer work together as expected. Same with testing the web client: you verify that the client / service layer works as required.

    And for integration tests I don’t see any reason to not use (tested) service layer methods.

    • 0