following situation:
tests.dll contains a bunch of unit
tests
program.exe contains some to be tested
classes
tests.dll contains tests using the
classes in program.exe
therefore tests.dll has a reference
on program.exe
nunit-agent.exe loads tests.dll and this then loads program.exe
--> basically in the nunit environment program.exe is used like a dll.
'misusing' an exe as dll is possible as i just wrote a little test application that also references program.exe and uses some classes defined in there and this runs fine ...
BUT in nunit i get a BadImageFormatException as soon as tests are loaded that use code defined in program.exe
is this a bug in nunit's reflection mechanism or is there a reason for that?
thx
tobi
This can happen if the .exe is compiled for x86 and you are running the tests on a 64 bit OS. If this is the case you may choose to use nunit-x86.exe for running the tests.
Related
I am using Specflow and firing the nunit-console.exe in TeamCity to run tests as follows:
"C:\Program Files (x86)\NUnit 2.6.4\bin\nunit-console.exe" /labels /include:regression out=TestResultRegression.txt /xml=TestResultRegression.xml /framework=net-4.0 .\MyTests.dll
How can I access the NUnit include tag (/include:regression) so that I can call certain methods or properties for test setup (ex. If include = regression, then run this certain pull these certain test case ids from the app.config file where the key is "regression")
There is no way in NUnit for you to know what runner is running you or how it is doing it. This separation of concerns is by design. You could, of course, access the command line that ran the tests and examine it, but I think that again forces the tests to know too much about their environment.
Best solution is to organize tests hierarchically so that all tests requiring a certain setup are in a namespace or fixture where that type of setup is performed.
I have a set of unit tests that use Shims from MS Fakes to test some static methods. I am currently using 4 fake assemblies, all of which reside in a single assembly. This fakes assembly is then referenced by the unit test assemblies that need it.
When we run locally in VS2013, all is fine, but when we try to do a build in Visual Studio Online, it fails with the following type of error:
MockLogManager.cs (25): 'ShimJsonLogger' does not contain a definition for 'LogGet'
Any ideas why it seems to be building the ShimJsonLogger but not giving it all of the properties we need?
I'm trying to get TFS team-build to reliably build a WPF C# app. This app relies on a VB6Lib.dll which we maintain, this VB6Lib.dll itself relies on other C# libs that we also maintain.
I've set up a build definition to build (in order):
VbDependencies.sln (all libs in this have com interop set, thus the VB6 can find their TLBs)
buildVB6Lib.proj (an msbuild file which calls "VB6.exe /make /d" to make the VBLib.dll on the build server, as part of this script I've been copying the VB6Lib.dll output to C:\tmp)
MainApp.sln (in my workspace, I've added a reference to C:\tmp\VB6Lib.dll)
Does this sound ok
?
On my dev laptop I usually build the VB6, copy its output to \tmp and then regsvr32 it there before adding a reference to it in my C# solution. It's this step that I'm not convinced my build def is doing.
Also, is there a way to get more useful output from the VB6 build, currently I get "Compile Error in File 'xxx.bas' Can' find project of library", but not which actual library it can't find.
You are correct in that the critical point in your build process on the development system lies in registering the COM object. However, one does not in general want to register the COM object on the build server, as this can cause all kinds of versioning issues and silent failures when the wrong COM object is registered or the registration fails.
The proper way to accomplish this is to generate an interop assembly manually and reference that instead of the COM object. This is accomplished with the tlbimp utility, for instance:
tlbimp ..\Libraries\VBLib.dll /out:..\Libraries\Interop.VBLib.dll
Run that command on your development system, then remove the reference to VB6Lib.dll and add a reference to Interop.VBLib.dll. You can then add the tlbimp command as a prebuild event in the referencing project so that the interop assembly is always build from the correct version, and you will never again need to have your COM object registered on the build system.
I have an automated build script which involves unit testing of some GWT Modules in production mode. It appears that when these tests are run, they recompile the GWT module.
However, earlier in the build script, I have already compiled the modules. This is an obvious waste of effort. Does anybody know of any way to test a GWTTestCase to run in production mode, on modules that were already compiled.
I don't mind losing stacktraces or any information, because the build server only informs developers of which tests fails, and expects them to debug in their own environment.
This will be helpful for you
The main class in the test infrastructure is JUnitShell. To control aspects of how your tests execute, you must pass arguments to this class. Arguments cannot be passed directly through the command-line because normal command-line arguments go directly to the JUnit runner. Instead, define the system property gwt.args to pass arguments to JUnitShell.
For example, to run tests in production mode (that is, run the tests afer they have been compiled into JavaScript), declare -Dgwt.args="-prod" as a JVM argument when invoking JUnit. To get a full list of supported options, declare -Dgwt.args="-help" (instead of running the test, help is printed to the console).
Running your test in Production Mode
When using the webAppCreator tool, you get the ability to launch your tests in either development mode or production mode. Make sure you test in both modes - although rare, there are some differences between Java and JavaScript that could cause your code to produce different results when deployed.
If you instead decide to run the JUnit TestRunner from command line, you must add some additional arguments to get your unit tests running in production mode. By default, tests run in development mode are run as normal Java bytecode in a JVM. To override this default behavior, you need to pass arguments to JUnitShell
-Dgwt.args="-prod"
Well, I found a solution, but it is not elagant. I modified JUnitShell.maybeCompileForWebMode method, you should add VM argument -Dcompile=false to prevent compilation while running unit tests . You can get modified version of JUnitShell from here .
I am currently trying to get my C# program to run on Linux. Using mono on my Linux machine, the program runs fine. So I used mkbundle and it all compiled and such correctly. But when I try to run the bundled program on any other Linux machine I get this error:
Unhandled Exception: System.TypeInitializationException: An exception was thrown by the
type initializer for System.Windows.Forms.XplatUI --->
System.TypeInitializationException: An exception was thrown by the type initializer for
System.Drawing.GDIPlus ---> System.DllNotFoundException: libgdiplus.so.0
This is the mkbundle command I used:
mkbundle --static program.exe --deps -o a.out
I also tried using mkbundle2 with no luck.
I thought maybe there was a way to specifically include libraries with mkbundle (like telling where to find libgdiplus). It should be linked in when I use mkbundle, but I guess it isn't because when I run my program on any other Linux machine (that isn't running mono), I get this error.
Both machines are running Ubuntu 10.10 AMD64.
The mono 3.0 config file for windos has bad entries dor the libgdiplus references.
Change the two lines of the file C:\Program Files (x86)\Mono-3.0.2\etc\mono\config
as follows:
<dllmap dll="gdiplus" target="/tmp/install/lib/libgdiplus.so" os="!windows"/>
<dllmap dll="gdiplus.dll" target="/tmp/install/lib/libgdiplus.so" os="!windows"/>
Extrernal helper libraries are not bundled in the executable, so you will either need to distribute libgdiplus as well, or use the -oo option to create an object file that you will link in a program together with the libs that you need. Of course you will also have to add a dllmap entry to map from, for example, libgdiplus to __Internal.
Note that if you just distribute the program generated by mkbundle as is, you're violating mono's free software licence, so unless, for example, you have a special licence from Novell, or you program is free software or you also distribute the object files of the app so people can relink themselves, you shouldn't use mkbundle.
If on your "foreign" machine you run this:
ldd a.out
You should be able to see what shared libraries it is expecting. You may need to distribute libgdiplus.so with your program or perhaps statically link in libgdiplus.a