2

Sometimes, ex. when using common mocks (same for data access layer as for presentation, I use often xunit ClassData), I come to the moment when I either copy common code to new unit test library or create "UnitTestsCommon" project.

I cannot find definitive answer which one is better, though I tend to rather duplicate in the name of simplicity and limiting dependencies. Is there a definitive answer to this and if so, what is it?

  • Possible duplicate of [Advantages and disadvantages to making common unit test scaffolding code](https://softwareengineering.stackexchange.com/questions/126627/advantages-and-disadvantages-to-making-common-unit-test-scaffolding-code) – gnat Mar 11 '18 at 10:36
  • What do yo do in your production code? – Stop harming Monica Mar 11 '18 at 13:16

1 Answers1

3

Its best to keep your tests together in a project which relates to the project you are testing.

MyProject
MyProject.Tests
MyLibrary
MyLibrary.Tests

Obviously duplicating code is a bad thing. But I think its a bad sign that you are needing to duplicate code. You don't want to link these two test projects as they should both ruin independently and just be concerned about testing their project.

Lets assume that both projects use the same dependency though, and therefore both tests need to mock that dependency.

You might be tempted to put that mocking setup in a common library. But I would regard that as a code smell. Do both tests really need the exact same setup? surely we are testing different behaviour.

However, Maybe you have an in memory version of the dependency which you use for mocking. That of course would go in its own library. which would perhaps be shared and uses as a mock in both test projects.

The thinking there being that The in-memory version is a real thing in of itself and the bespoke setup logic would still be contained in each test project.

Ewan
  • 70,664
  • 5
  • 76
  • 161