Open tboyce opened 10 years ago
I haven't actually tried this; though I'd seen mention of *.TestAdapter.dll before. I was under the impression that was only required if you were trying to have it picked up as a loose DLL; not if it was "installed"; but that was for local machines; not sure how TFS builds work.
How are you getting the DLL in to the build server? Are you committing it somewhere; or is it installed? I'm happy to shuffle things around (and rename the DLL) to make this easier; though I have no TFS to test with (though if it's all the same as Visual Studio Online; I can use that).
I basically followed the steps as documented here here, except for step 2, which I don't think is necessary even for NUnit. I extracted the assemblies from the VSIX, added them to source control, told the build controller where to find them, and added a Test Run to my build definition for "*.testxml". The final step to get it working was to copy DanTup.TestAdapters.Xml.dll and name it DanTup.TestAdapters.Xml.TestAdapter.dll. TFS then was able to load and use the adapter.
I don't know if you would be able to do the same with Visual Studio Online, but it may be possible.
Thanks for the info! If that works without step 2, I think I can make it even simpler with a NuGet package. If you have a *.TestAdapters.dll in a NuGet, it'll get picked up automatically.
However, I'm surprised that works without installing the vsix, because in my testing Visual Studio wouldn't match up the file extension with the tests unless it was a full blown install.
I'll try to do some testing in the next few days; would be nice if I could ship this as a NuGet package that just worked, without anyone needing to install nasty Visual Studio vsix extensions!
TFS builds probably behave a bit differently from Visual Studio in that regard. You can add a "Test Run" to a TFS build definition and give it a file extension (step 4 in that NUnit guide). During the testing phase of the build, it will then attempt to locate a test adapter that can handle that extension. In the standard build templates, there is a default Test Run for .exe and .dll, so I think adding *.testxml would still be required if your assembly was included via NuGet.
Right; that explains the difference :)
If I put a TestAdapter.dll into a NuGet package; it works fine for exe/dll, but nothing else. I need the VS extension in order to tell VS to monitor other file types. Sounds like that TFS config is the equivalent. Shame we can't do it without the extension locally; yet can on TFS :/
There might still be merit in throwing the DLL into a NuGet package with a TestAdapter.dll extension; it'll make it slightly easier to get working on TFS. However it might be slightly confusing for local runs; as the NuGet on its own won't show you the results :O(
I tried following the step for the Build Server, but could not get it working. This is what i have tried. On Visual Studio Project(VS2013) 1) Create a folder by name ThirdPartyDlls 2) Copied the both the dll DanTup.TestAdapters.Xml.dll into this folder and renamed it as suggested 3) set the build action to Content and always Copy
On TFS Build Server (TF2013) 1) Modified the Test Run to Include (*.testxml) 2) PreTest Event, Execute the JavaScript Unit Test using Grunt(using Powershell)
Verified that the "testxml" file is generate on the build server, prior to TestExecution on the build server.
What am i missing or doing wrong way ?
The problem might be in your VS2013 step 2. I actually had to copy the file, not rename it. TFS finds the file named *.TestAdapter.dll, but then actually loads the original one when executing the tests. Not sure why.
I have checked in to TFS: DanTup.TestAdapters.dll DanTup.TestAdapters.Xml.dll DanTup.TestAdapters.Xml.TestAdapter.dll
After much head scratching trying to get your Karma adapter to work with a TFS build, I have discovered that the assembly must be named *.TestAdapter.dll to be detected by the Visual Studio Test Runner.
Great work, btw. I now have JavaScript unit test results in my builds.