CODEWITHSUNDEEP
c#testingdll
Amorphis
Amorphis

Reputation: 398

Test Methods and Test Class in compiled DLL

Is there a way in Visual Studio (Any version) to use Tests from compiled Dll's?

I have a Test Class:

[TestClass]
Public Class TestingClass
{
    [TestMethod]
    public void TestingMethod()
    {}
}

Is there a way to compile the class library that hold this kind of class's into a Dll and reference that DLL in a different Test Project so they will show up in the Tests View?

I've tried simply compiling the Library and referencing it and it in a different project and the tests are not shown in the Tests View.

Upvotes: 1

Views: 2332

Answers (3)

user3988148
user3988148

Reputation: 87

What you are asking is near impossible to do, because the test framework tends to be dynamic. One of the things that fail the most is finding elements (UI testing), therefore, if I can't change or add code to the finder methods in the framework (because they are in a dll), then I'm up the creek because is something that happens frequently. Or to add any other helper that may be needed. In other words, creating a dll for a framework may not be the way to go. Having a repository for the framework where only the architect can make changes to it and others can clone as necessary may be an easier way, however, some DevOps engineer may bark about it.

Upvotes: 0

nicolasm
nicolasm

Reputation: 36

This was resolved with parameter EnableBaseClassTestMethodsFromOtherAssemblies in RunSettings which is now enabled by default.

https://github.com/microsoft/testfx/issues/23

Upvotes: 2

forsvarir
forsvarir

Reputation: 10839

I doubt there is a built in way to do this, because it's not a normal use case, in fact I'm finding it hard to picture a scenario where this is going to be the right thing to do.

The normal approach to testing would be to create a code project, then create a test project that has a reference to the code project. Generally speaking this makes sense, the tests need to know how to instantiate and call out to the code they're testing. In the scenario you're describing, what would the tests be being run against?

Maybe you're doing something different, like loading the dll to be tested with reflection, or you're disconnected from it in some way such as via a service call but in either scenario it still feels like there might be a better approach to follow than publishing a test dll.

From a user perspective, I can think of nothing quite as frustrating as being given a bunch of tests, that I can't see the contents of and told to make sure they work against my code. Whilst I'm sure you've gone the extra mile to name your tests well, to ensure each test is only testing one, obvious thing and to ensure that all test failures would give meaningful feedback, I can't help but feel like the end result will be people burning hours trying to fix tests because they've misinterpreted what the test was asking for, which could be avoided if they were able to actually read the test code.

Scepticism aside, if you really do have a need to do this, then one approach would be to give them a project + a compiled assembly. The compiled assembly has your real tests in it, and your source project simply has classes that wrap your test project, using inheritance. So, public class TestWrapper : SuperSecretTests. The testing engine will pull in tests from the base class, without the base classes code needing to be available.

You could also just require that these tests are run via the command line, rather than from within visual studio. Both mstest and vstest.console allow you to specify a dll containing tests to run against.

Upvotes: 1

Related Questions