Add support for DLL projects

[kkutsner]

I apologies if my question has been asked already somewhere, but are you looking toward adding support for Shared Library projects? From my understanding, it works only for executables for now and there is no way make it work against dll without adding a project configuration to produce executable specifically to run unit tests. It would be nice to get it working without blowing up the list of existing project configurations - at least, this is a concern for some huge projects which I'm working on. From my understanding the adapter should spin a process (e.g. RunDll32.exe for X86 and something else for X64) to load the library, locate the entry of google test runner and execute it with required parameters.

Ultimately, I'm curios about way to solve slightly bigger issue. There is an approach to keep unit tests along with source code under the same project. It could share the same build configuration and there should be an easy way to enable/disable tests within one button click. For example, when developer checks "Test->TestSettings->Keep Test Execution Engine Running" (or may be separate menu command) it could propagate a build property e.g. $(VsTest) which may be set as preprocessor definition under the compiler settings, e.g. VS_TEST which you could use later in your code to define when unit tests need to be compiled into the binary. I'm kind of sure it is not something that can be addressed at test adapter level but I'm keeping it here just to better describe why creating a separate project configuration for unit test does solve the problem. For now, I've got a separate menu button at Build menu to toogle unit tests compilation which works somehow for executable projects and would be nice to get it working for dlls in the same way...

[csoltenborn]

Looks like a reasonable enhancement at first glance - we'll think about it and let you know!

[profan]

Hi! Is this still under consideration, or alternatively if one would look at implementing this, how much work would it be do you reckon?

[csoltenborn]

To be honest, I do not have much time currently for GTA, so this is not going to be tackled in the foreseeable future by me. Of course, a PR would be great!

And to be honest once more, I'm not sure how much work it would be :-), but I would of course be willing to help with advice as far as GTA itself is concerned... The automated test suite is in a reasonable shape, which should certainly help, I guess.

[profan]

Thanks for the heads up 👍 I'll check it out then and will see if it's a massive task or not, otherwise I will probably have a crack at it as it's something I happen to need :)

[csoltenborn]

Ok, sounds great! I will help you be making a release this weekend: I have a feature (support for setting environment variables) in develop branch which is not yet released, plus some minor bugfixes. That way you should have a cleaner state to base your work on.

Please branch from develop branch anyways, and please do not forgot to add according sample projects to the SampleTests solution and automatic tests to the GTA solution ;-)

Despite that, let me know if you have any questions...

[csoltenborn]

Just to let you know: I finished housekeeping, develop branch is ready to receive your contributions!

[profan]

My other avenue for testing kind of worked out unexpectedly (VS own test framework, which is vey unfortunately proprietary), but I may still get back to do this later because debugging VS's own unit testing framework is absolutely terrible when things don't work.. you get some error code like "Failed to set up execution context" in a binary blob you can't inspect when so much as a single DLL (in your code) can't be loaded by the executor DLL.. (I ended up running strings on all the DLLs to find out where it was even coming from).

So thank you either way, hopefully I'll be able to get on this soon 😅