Improved Test Discovery

[dennisknudsen18]

First: Thanks for the effort on GTA.

Feature request:

I'd like to see some extras on the discovery of tests. In our shop, we're transitioning to GoogleTest, so slowly, so there are still some CPPUnit projects around, and even some C# test .EXE projects around, with names that are not easily masked by a regex, and names that not easy to change due to other dependencies.

So I suggest that GTA test discovery is extended to look for other signs that this is indeed GT runnable, such as:

• Presence in the VS project of a certain file, such as 'is_googletest_project.txt'
• VS Project is an .EXE exporting a named function (declspec export IS_GOOGLETEST_PROJECT)

[csoltenborn]

Thanks for your feedback and the kudos!

I think that I understand your problem. However, what you can always do is provide a regex such as foo\.exe|bar\.exe, which will match exactly the executables foo.exe and bar.exe. Did you consider this?

Having said that, your first suggestion should be rather easy to realize if the is_googletest_project.txt
file is located within the same folder as the executable (note that the VS framework only provides the solution's directory to the test adapters - we do not know of any way to reliably figure out the project directory of a given executable). I will discuss this with my former developer Jonas.

Your second suggestion, however, has the drawback that we have to parse each project's pdb file only for the matter of figuring out whether it is indeed a Google Test executable. I think that this has performance penalties we are not willing to take. Again, I will discuss this with Jonas.

Feel free to add your thoughts on mine :-)

[dennisknudsen18]

I'll try out the specific regex'es to see how long they get, thx.

Project file:
You should be able to use the VS project 'stuff', either the extensibility objects or the old one; there's a guy somewhere that does this for Java tests if I remember correctly.
(I think the link is https://github.com/pimterry/chutzpah/blob/master/VS2012.TestAdapter/ChutzpahTestContainerDiscoverer.cs)

.EXE export.

I think you already know the name of the .EXE, so if that exports a specific function, I think that's a very good sign. This will load the .EXE, which might be a performance penalty, but you don't need to load the PDB for this, and the .EXE image is probably 'hot' in many cases.

Something like this on the discovery side:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Runtime.InteropServices;

static class NativeMethods
{
[DllImport("kernel32.dll", EntryPoint = "LoadLibrary")]
public static extern int LoadLibrary([MarshalAs(UnmanagedType.LPStr)] string lpLibFileName);

[DllImport("kernel32.dll", EntryPoint = "GetProcAddress")]
public static extern IntPtr GetProcAddress(int hModule,[MarshalAs(UnmanagedType.LPStr)] string lpProcName);

[DllImport("kernel32.dll", EntryPoint = "FreeLibrary")]
public static extern bool FreeLibrary(int hModule);

}

namespace MyCppUnitAdaptor.Helpers
{
public class AHelper
{
public static bool IsGoogleTestExe(string theexe)
{
int theDll = NativeMethods.LoadLibrary(theexe);
bool res = false;
if ( theDll != -1)
{
int pa = (int) NativeMethods.GetProcAddress(theDll, "I_Am_Truly_A_GoogleTest_APP");
if (pa > 0)
res = true;
NativeMethods.FreeLibrary(theDll);
}
return res;
}
}
}

And in the test application, main.cpp - or whereever -

__declspec(dllexport) void __cdecl I_Am_Truly_A_GoogleTest_APP(void);

[dennisknudsen18]

Whoops, not so used to markdown. Hope it works out. The exe export should work just fine.

[dennisknudsen18]

btw, if the 'find solution file' doesn't work out, you might consider looking for a file named after the project, like
mytest.exe.is_gta.txt
and then have MSBuild copy the file on build to the output directory, then they should be side-by-side.

[csoltenborn]

Oops, I forgot to update this issue - in fact the "file marker" solution has already been implemented. If you want to give it a try, feel free to use this build (and note the updated Readme.md).

We are going to look into the dllexpexport approach, but are busy with other things at the moment, so give us some time...