Re-using code in unit tests -

i have rest web-service interface calls-down service layer orchestrates creation, deletion, etc. of various objects in entity-layer. these entity-layer objects map database records. have number of unit tests (in nunit, c# application) test interface sending http requests.

consider testing of web service request creates entity-layer object. want verify web service considers request have been processed correctly, checking http status returns me plus data in response body. want independently verify correct database records have been created. have couple of ways (that can think of) this:

• the easiest way use existing 'reader' classes in entity layer read , validate database entries. easy because incorporate validation , consistency logic entities deal with, , using them simple. uneasy this, though, because using code i'm testing part of test. seems violate principle of separation of concerns, , introduce possibility of entity-layer bug causing object creation fail appear unit test have succeeded.

• alternatively, test code go straight database , checks itself. i'm embedding details object storage , consistency rules in test - makes test brittle if details change, , means re-implementing, in unit tests, code i've written in entity layer.

i wonder people think of trade-offs involved these (and maybe other) options, , (if any) best practice? i'm not sure if there right or wrong answer, i've wondered while , interested in other opinions.

edit

to clarify, save separate test suites service-layer , entity-layer. concerns have expressed -- using tested code in test -- apply these tests.

we see 2 different tests, test of service methods , test of webclient.

for testing service methods (like reader), may want create database predefined values (test data), call reader, , test, if readers output matches test data in required way.

once you've tested service methods, can move next test level , test web client, again using same test data testing if data shown on web client matches test data in required way. on test level, can "trust" readers (because have been tested before).

---

maybe feel more comforable if separate between "unit testing" , "integration testing". unit testing, verify compilation unit works required. testing reader: populate database defined data, call findall() (or else), , assert test data , test data in result.

the other test integration test - there verify, service layer , entity layer work expected. same testing web client: verify client / service layer works required.

and integration tests don't see reason not use (tested) service layer methods.