I'm using Nunit console 3.8 in my automation tests.
When I run the same command with different param value in the same machine few times, I see that the first value in all cases.
Does Nunit consoles' params have a cache on the disk? Can we clear it?
"c:\...\nunit3-console.exe" <DLL List> --params=testLevel=Sanity /where:"cat == <some_category>"
"c:\...\nunit3-console.exe" <DLL List> --params=testLevel=Regression /where:"cat == <some_category>"
Related
I'm running the following command to run my .net Core tests:
dotnet test
This runs fine. I want to now generate code coverage stats, so after following this article, I ran this:
dotnet test AI.Core.Tests.csproj
/p:CollectCoverage=true
/p:CoverletOutputFormat=cobertura
/p:CoverletOutput=TestResults\Coverage
I get the following output from this command:
C:\Users\sp4_rm\.nuget\packages\coverlet.msbuild\2.2.1\build\netstandard2.0\coverlet.msbuild.targets(23,5): error :
Index was out of range. Must be non-negative and less than the size of the collection.
[C:\Users\sp4_rm\Desktop\EVO\AI.Core\src\Tests\AI.Core.Tests.csproj]
C:\Users\sp4_rm\.nuget\packages\coverlet.msbuild\2.2.1\build\netstandard2.0\coverlet.msbuild.targets(23,5): error :
Parameter name: index
[C:\Users\sp4_rm\Desktop\EVO\AI.Core\src\Tests\AI.Core.Tests.csproj]
See screen shot below:
Has anyone got this command running? What am I doing wrong?
Ok so this was due to a school boy error in not actually have any code to test (or test case to test it) in my sample project!! Adding a couple of classes into the main projects and a couple of tests in the test project does away with this problem! (just in case anyway does the same thing as me!)
I have created an release app with rebar3 (beta-4).
Added some eunit tests and wrote some code.
For now I have to debug one test case to see what I have to add to make the implementation to work properly.
I found some articles about using dbg from Erlang console and I found how to write debug info from Eunit. But I need to get info from code that I have to test (the actual implementation(logic)).
Is there a way to debug Erlang code (actual source code, not the test one) when rebar3 is used with eunit argument?
I'm using tracing in terminal like there: https://aloiroberto.wordpress.com/2009/02/23/tracing-erlang-functions/
One way to do this is use rebar3 to run a shell under the test profile, then start the debugger and set up your breakpoints and such:
$ rebar3 as test shell
...
1> debugger:start().
{ok, <0.67.0>}
This will pop up the debugger GUI. Once the debugger is set up and ready, run your test under eunit:
2> eunit:test(your_test_module,[verbose]).
======================== EUnit ========================
your_test_module: xyz_test_ (module 'your_test_module')...
Assuming you set up a suitable breakpoint in the debugger, this will hit it, but you'll likely run into a problem with this approach: by default, eunit tests time out after 5 seconds, which doesn't give you much time for debugging. You need to specify a longer timeout for your test, which is why the example above shows that what's running is a test fixture named xyz_test_, which wraps the actual test with a long timeout. Such a fixture is pretty simple:
-include_lib("eunit/include/eunit.hrl").
xyz_test_() ->
{timeout,3600,
[fun() -> ?assertMatch(expected_value, my_module:my_fun()), ok end]}.
Here, the actual test is the anonymous function, which matches the return value from my_module:my_fun/0, which for this example represents the business logic under test. This example fixture sets the test timeout to one hour; you can of course set it as needed for your application.
This question requires an understanding of both the Window's start command's behavior and a custom gradle ExecTask's handling of it.
Question
Why does start, with an application as a parameter, wait for the application to exit, only when being executed within a gradle ExecTask?
Explanation
From the command line, this works as expected (starts the application and returns, without waiting for the application to exit):
cmd /c myBuildEnvironment.cmd && start "some title for start" devenv.exe my.sln
Pretty simple, it calls a windows batch script to setup the environment and then launches my.sln in Visual Studio. Works just fine, not waiting for Visual Studio to be closed. And, this is what my gradle task is meant to achieve.
The same works "somewhat", using the following gradle ExecTask with start:
/**
* I know that the executable + args is replaced by commandLine. They're
* just there for readability.
*/
task openVsSolution(type: Exec, dependsOn: setupVsSln) {
description 'Opens the VS solution, in the appropriate version of Visual Studio.'
executable 'start'
environment = taskEnv
workingDir '../../src/solution'
args = [vsDevEnv, 'my.sln']
commandLine winCmdPrefix + executable + args
}
Gradle happily reports Build Successful, while Visual Studio remains open.
However, I say "somewhat" because start will actually ignore the executable argument and open my.sln with the default application for it, Microsoft Visual Studio Version Selector. So, after some research, I found that start assumes that the first parameter is the window title, then application, and lastly, the application arguments. So, I tried this:
task openVsSolution(type: Exec, dependsOn: setupVsSln) {
executable 'start'
environment = taskEnv
workingDir '../../src/solution'
args = ['some title for start', vsDevEnv, 'my.sln']
commandLine winCmdPrefix + executable + args
}
Everything works, start used the correct version of Visual Studio's devenv.exe, which varies based on the VC PlatformToolset, but...gradle sits in the background waiting for Visual Studio to close.
Why? How can I achieve all of the desired behavior?
Update
This might be an environmental problem. Apparently, on one dev's machine, the original gradle start task does stay open, as well. So, any invocation of start through gradle waits for it to complete, in a certain environment. The plot thickens...
Gradle is waiting for start to return is my guess, see this post - Run a background job from Gradle. Read also the comment after the answer, this is started from Java so if there is equivalent of & (run in background) for windows, it wouldn't work.
You can also try and wrapping it in a bat file, execute what you want in the bat file in the background then return right away so that gradle would be happy.
Hope this helps.
I found a command-line tool called "xctest" that apparently can run the unit tests in your project. This executable lives here:
/Applications/Xcode.app/Contents/Developer/usr/bin/xctest
When I try to run this executable on my xctest bundle, I'm using:
$ ./xctest /Users/myusername/Library/Developer/Xcode/DerivedData/MyApp-abcdefghijklmnop/Build/Products/Debug/MyAppTests.xctest
However, I get the following output:
Test Suite '(null)' started at 2013-11-14 21:16:45 +0000
Test Suite '(null)' finished at 2013-11-14 21:16:45 +0000.
Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.001) seconds
There's no man page for xctest, as far as I can tell, but entering just ./xctest at the command-line yields:
Usage: xctest [--test Self | All | None | <TestCaseClassName/testMethodName>] <path of unit to be tested>
In particular, I'd like to be able to test just a particular method in a test class, which is why I'd like to use this xctest command.
I do see that there is a way to run all the tests from the command line like:
$ xcodebuild test -scheme MyApp
This runs all the unit tests and works properly (I see my unit test results, unlike when using xctest). But I'm interested in being able to run a single test method from the command-line, such as:
$ ./xctest --test MyAppTests/testExample /Users/myusername/Library/Developer/Xcode/DerivedData/MyApp-abcdefghijklmnop/Build/Products/Debug/MyAppTests.xctest
Despite what the usage message says -XCTest is the argument you need:
xctest -XCTest MyAppTests/testExample testbundle.xctest
For a direct invocation of xctest to work you may also need to set DYLD_FRAMEWORK_PATH and DYLD_LIBRARY_PATH to your built products directory. In general you need to use the same arguments and environment as Xcode does, you can see this by putting a breakpoint in one of your tests, running them through Xcode, then printing out the values of arguments and environment for [NSProcessInfo processInfo].
To avoid messing with all that note you can also modify the scheme in Xcode to run only specific tests. Under Product > Scheme > Edit Scheme select the Test action and expand the test bundle. You can use the check boxes to select the tests to run and xcodebuild's test action will then run only these tests.
I'm getting the following error when installing my ClickOnce application via firefox. It doesn't happen with IE on the same computer. I swear I've installed it via firefox before. This is a Windows 7 machine.
The following properties have been set:
Property: [AdminUser] = true {boolean}
Property: [ProcessorArchitecture] = Intel {string}
Property: [VersionNT] = 6.1.0 {version}
Running checks for package '.NET Framework 2.0 (x86)', phase BuildList
Running external check with command 'C:\Users\luke\AppData\Local\Temp\VSDEF1A.tmp\DotNetFX\dotnetchk.exe' and parameters ''
Process exited with code 1
Setting value '1 {int}' for property 'DotNetInstalled'
Reading value 'Version' of registry key 'HKLM\Software\Microsoft\Internet Explorer'
Read string value '8.0.7600.16385'
Setting value '8.0.7600.16385 {string}' for property 'IEVersion'
The following properties have been set for package '.NET Framework 2.0 (x86)':
Property: [DotNetInstalled] = 1 {int}
Property: [IEVersion] = 8.0.7600.16385 {string}
Running checks for command 'DotNetFX\instmsia.exe'
Result of running operator 'ValueExists' on property 'VersionNT': true
Result of checks for command 'DotNetFX\instmsia.exe' is 'Bypass'
Running checks for command 'DotNetFX\WindowsInstaller-KB893803-v2-x86.exe'
Result of running operator 'ValueExists' on property 'Version9x': false
Result of running operator 'VersionLessThan' on property 'VersionNT' and value '5.0.3': false
Result of running operator 'VersionGreaterThanOrEqualTo' on property 'VersionMsi' and value '3.0': true
Result of checks for command 'DotNetFX\WindowsInstaller-KB893803-v2-x86.exe' is 'Bypass'
Running checks for command 'DotNetFX\dotnetfx.exe'
Result of running operator 'ValueNotEqualTo' on property 'DotNetInstalled' and value '0': true
Result of checks for command 'DotNetFX\dotnetfx.exe' is 'Bypass'
'.NET Framework 2.0 (x86)' RunCheck result: No Install Needed
Launching Application.
URLDownloadToCacheFile failed with HRESULT '-2146697211'
Error: An error occurred trying to download 'http://croppy.lukehunter.net/download/croppy.application'.
The following is the howto from Microsoft, but this doesn't apply to firefox. There is no redirection happening either.
If a user has set Internet Explorer
Advanced Security option "Warn if
changing between secure and not secure
mode" on the deployment target
computer, and if the setup URL of the
ClickOnce application being installed
is redirected from a non-secure to a
secure site (or vice-versa), the
installation will fail because the
Internet Explorer warning interrupts
it.
Internet Explorer calls either LaunchApplication or ShOpenVerbApplication procedure from dfshim.dll behind the scenes, whereas Firefox plug-in (as well as a standard bootstrapper created by Visual Studio 2008-2010, which could also produce this rare error) uses a different, out of date technique to launch ClickOnce applications. (Note, that LaunchApplication requires at least .NET Framework 2 SP 2.)
To avoid such error one could redirect Internet Explorer to a deployment manifest (.application) and all other browsers to a custom installer (.exe) that would install .NET Framework if necessary and then call ShOpenVerbApplication.
Hmm, after using IE to install, then uninstalling, I was able to install via firefox again. Odd.
The following worked for me:
Within the local distribution package CLICK ONCE a web.config file was generated on line clientCache that was the problem, in which altered as follows for CHROME and IE8 and now run the file:
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" />
I've had this and it to resolve it was to disable the firewall. I sadly don't know what Firewall settings it was, I just disabled the lot and it ran/installed without issue.
After exhausting firewall options on this issue, I found that my excutable was pointing to the IP Address of the Application Server. When I changed the site deployment and consequently the executable to the FQDN of the server instead of the IP Address, the installer worked first time.
Simple Solution, on cmd execute setup.exe /URL=http://< Production URL>/
Easy!