How to name Test Projects

Question

Suppose I have some Modules that each are their own component

Modules

I would now have different Testprojects spanning different modules. UnitB_UnitTest, UnitC_UnitTest, GUI_UnitB_ComponentTest, GUI_UnitB_UnitC_HDD_SystemTest

If I concatenate every Modulename involved in a Test with underscore the names will get huge and different ordering would make them not unique.

How should you name the different testing projects?

EDIT:
(1a) What is a "project" in this context?
When I think about this I actually think about Visual Studio Projects. I could further group them into Solutions, but that to my mind only makes sense for Units and their Unit_Tests.
(1b) What kind of test framework are you using (e.g. an xUnit-style framework)?
Yes, xUnit. For C# i would use NUnit, for C++ i would either go with googletest or boost::test.
(2) Why don't you put the unit tests into the same project as the module they are testing?
It makes total sense to group unit tests ans units. But that once you start with integration tests you could start to run into issues. You could logically group them but what would your naming be then?
(3) Why don't you have a single project for all integration tests?
What advantages does it have to separate the GUI–Unit B integration tests from GUI–Unit C into separate projects?
I did not think about that but my gut tells me that this may be a problem when different teams work on the same CI system.

• amon: A couple of questions for clarification – feel free to edit your question with further details: (1) What is a "project" in this context? What kind of test framework are you using (e.g. an xUnit-style framework)? (2) Why don't you put the unit tests into the same project as the module they are testing? (3) Why don't you have a single project for all integration tests? What advantages does it have to separate the GUI–Unit B integration tests from GUI–Unit C tests into separate projects?
• Robert Harvey: You have several possible levels of abstraction available to you: namespaces, classes, modules, methods, regions. Projects is just one possible level of abstraction; make sure you're taking full advantage of the others. For what it's worth, you should probably have as few projects as you possibly can. Maintaining complex relationships between too many projects can be quite difficult.

Answer 1

You have several possible levels of abstraction available to you: namespaces, classes, modules, methods, regions. Projects is just one possible level of abstraction; make sure you're taking full advantage of the others.

For what it's worth, you should probably have as few projects as you possibly can. Maintaining complex relationships between too many projects can be quite difficult.

Rule of thumb: Use one Test project per project under test, which will contain all of the tests for that particular project under test, including the Unit Tests and Integration tests. Separate these test types by using different namespaces, if you wish.

For naming, you can simply use NameOfProjectBeingTested_Tests.