2

Looking to include unit tests in a whole host of new solutions. Not sure how to structure them.

Not sure if it really matters, though these are all .Net C# projects.

I have read many similar answers, such as this one Organization of Unit Tests in Visual Studio and this one Do you put unit tests in same project or another project? but none appear to address projects that are shared across multiple solutions

Given the structure of the 2 solutions below, what would be best-practice for creating unit test projects.

Solution #1

  • Data - Solution Folder
    • MyData - Project
  • Global - Solution Folder
    • Global.Project.1 - project
    • Global.Project.2 - project
    • Global.Project.3 - project
    • Global.Project.4 - project
  • Services - Solution Folder
    • Service.Project.1 - project
    • Service.Project.2 - project
  • Web - Solution folder
    • MyWebsite - project

Solution #2

  • Data - Solution Folder
    • MyData - Project
  • Global - Solution Folder
    • Global.Project.1 - project
    • Global.Project.2 - project
  • Services - Solution Folder
    • Service.Project.1 - project
  • App - Solution folder
    • MyConsoleApp - project

Notice that there are some projects that are shared between the solutions.

So the question, what are the typical approaches to these?

Would we create a test project per project?

Or a single test project per solution?

Or some hybrid between the two, perhaps a solution of their own

Any pitfalls that come to mind over the different approaches?

Community
  • 1
  • 1
Darren Wainwright
  • 30,247
  • 21
  • 76
  • 127
  • Not sure how this is "too broad" - care to elaborate? It's more concise than the other questions referenced. – Darren Wainwright Apr 25 '17 at 18:32
  • It´s rather opiniated than "too broad" I guess. I doubt there a "right" or even a "common" way to do this, it´s mostly driven by personal preferences. In our company we´re actually implementing one test-project per software-component where every component cinsists of a bunch of assemblies. – MakePeaceGreatAgain Apr 25 '17 at 18:35
  • Possibly - have attempted to keep it less opinionated though; there must be some 'typical' ways of doing this. It's not like there are dozens of different ways to achieve what I'm asking. – Darren Wainwright Apr 25 '17 at 18:36
  • Even then the question doesn´t fit into the rules of SO as there´s no "right answer" to be chosen. – MakePeaceGreatAgain Apr 25 '17 at 18:37
  • And yet both questions referenced garnished multiple answers and many up-votes between them. I've gone a little further and want to know about testing shared code. – Darren Wainwright Apr 25 '17 at 18:39
  • The linked questions are 8 and 9 years old. Standards of acceptable questions have changed. – krillgar Apr 25 '17 at 18:42
  • The reason why those questions got upvotes is that they are quite old. However SO emerged much in time and questions that where considered good questions are low quality ones nowadays. Thus refering to those as good basis for your researches isn´t good idea. Anyway you should go the way that is most accepted in your team, there´s no single answer. – MakePeaceGreatAgain Apr 25 '17 at 18:42
  • Furthermore a question can be upvoted and thus considered to be usefull whilst not fitting into SOs rules. It may be closed thus, however gets some votes and (before closing) even some answers. Anyway I suppose the referred question would nowaydays be closed soon. – MakePeaceGreatAgain Apr 25 '17 at 18:44

1 Answers1

3

I have always done it one-to-one with projects and unit test projects.
Any project that can stand on it's own needs to be tested on it's own. Otherwise you're coupling it with all other code in the test project.

For testing code which requires more than one of the projects, you would mock the objects from other packages, or you can follow the clear inheritance hierarchy. i.e. tests in Web can use the classes in Data, but should not be testing the functionality of Data.
You can also create a new test project for the combined testing, this is often more useful in the scenario of an integration test, where you are testing a live -but not production- system.

Within the solution, these would be divided into a Test folder, which would be divided into the same folders as the projects themselves. i.e. your Test folder would contain Data, Global, Services, and Web as separate folders.

It is also useful to have a master solution. One that contains all projects. This way, you can be sure that a change to Data will not break some other solution's Web tests, even if it doesn't break your current ones.

If what you're really doing is creating some shared libraries, you should look into hosting your own nuget repository. This helps sort out versioning issues in the shared code.

Jean-Bernard Pellerin
  • 12,556
  • 10
  • 57
  • 79
  • Great response, many thanks. I've been going down the route of what you've suggested though as the team adopts more unit testing it's not easy to see pitfalls. Hosting our own nuget is something we've talked about though a little away from. Something i will for sure look into though! – Darren Wainwright Apr 25 '17 at 18:48
  • 1
    Marking this as accepted - not because answers are in short supply but that it accurately gave ideas and reasons. Thanks again. – Darren Wainwright Apr 25 '17 at 19:17