1

I have code in a (Visual Studio) Shared Project, and a number of end solutions/projects which compile and build the Shared Project to various environments (repo).

When writing unit tests, I will want to unit test for each environment.

Should my test project reference the code in the Shared Project directly? Or should I reference the output dlls?

4
  • I heavily recommend to make your question more self-contained, which means you have to explain which solutions and environments you have (the question should be understandable for someone who does not follow the link to GitHub). External links tend to have a shorter life-time than questions on this site. Also, your question does not show us the research you already did before asking - please add some words what you tried and why it did not suit your needs..
    – Doc Brown
    Nov 13, 2019 at 6:54
  • @DocBrown I'm not sure what further details I should add. The question is a general one: should I be testing against source code or against the compiled dlls? (Should that be the body of my question?) I don't think the specific environments aren't really relevant. RE research: I Googled unit test dll or shared code and didn't find any results that answer this specific question.
    – Zev Spitz
    Nov 13, 2019 at 9:09
  • 1
    "When writing unit tests, I will want to unit test for each environment." I don't understand why the environment would make a difference to the behavior. What is the point of having a shared library being used in multiple environments if the expectation is that it will behave differently in different environments? It seemingly defeats the purpose of abstracting away your reusable logic as it's then not provably reusable.
    – Flater
    Nov 13, 2019 at 12:43
  • @ZevSpitz: yes, I guess you are right, the "different environments" is only a red herring, consider to remove that part completely, since it only distracts from the core question.
    – Doc Brown
    Nov 13, 2019 at 13:46

1 Answer 1

2

Simple "rule of thumb": when creating unit tests for a shared DLL, try to use the same mechanism for referencing as regular client code which uses this DLL.

Since you want your unit tests to "simulate" the behaviour of a "production client", it is usually recommendable to do this in a similar fashion, in all aspects, including the reference mechanism.

Said that, when you are the one who is actively developing both, the shared library as well a project which uses them (like your unit tests), and want to keep both projects in the same solution file, use a project reference, not a DLL reference. Read also this older SO post.

This has actually not much to do with the fact you are compiling your program for different environments. You have to decide, of course, if you want a shared unit testing project for the shared project, or if you require different unit testing code for each of the environments, but this decision is independent from the reference mechanism you choose.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.