We are getting the tests to execute from our testcase management tool and have stored their id in the list .
Example:
List<string> caseid = new List<string>() [ "tc1", "tc2", "tc3" ]
Now I want to execute all the test cases at once/simultaneously to take advantage of my parallel execution system where I an utilise up to 24 browser instance.
Currently I am iterating over this list and executing as
dotnet test --filter TestCategory=caseid[i]
Here testcase id is also used as #tag.
If there is a way to execute all the tests in the list at once
Try the following syntax:
dotnet test --filter "TestCategory=tc1|TestCategory=tc2|TestCategory=tc3"
If you have large number of tests, you can just generate .sh file for MacOS or .cmd file for windows to run desired batch of tests:
var filter = String.Join("|", caseid.Select(id => $"TestCategory={id}"));
File.WriteAllText("./runbatch.sh", $"dotnet test --filter \"{filter}\"");
and then run tests in terminal:
sh runbatch.sh
I have an issue with test coverage. When I run this command
dotnet test ../XZrcndee.sln --output ../coverage /p:CollectCoverage=true /p:CoverletOutput=results\coverage /p:CoverletOutput=..\results\coverage /p:MergeWith=..\results\coverage.json /p:CoverletOutputFormat="opencover"
It show me that codecoverage is 0
When I try run dotnet test in only one project I got the correct result.
dotnet test ../XZrcndee.Domain.Tests/XZrcndee.Domain.Tests.csproj --output ../coverage /p:CollectCoverage=true /p:CoverletOutput=results\coverage /p:CoverletOutput=..\results\coverage /p:MergeWith=..\results\coverage.json /p:CoverletOutputFormat="opencover"
Do I miss somthing?
Kind Regards
Try this
dotnet test ../XZrcndee.sln --output ../coverage /p:CollectCoverage=true /p:CoverletOutput=results\coverage /p:CoverletOutput=..\results\coverage /p:MergeWith=..\results\coverage.json /p:CoverletOutputFormat="opencover" /maxcpucount:1
make sure to cleanup the "coverage.json" after each run otherwise it will merge results from mulitple runs also.
I am working on a fresh .netcore api project. I am trying to deploy the application using octopus.
I need help on executing the migrations from command line and I am not getting a lot of help. If some one can help me it will really help.
Here is what I have tried so far:
I have taken help of the following link to come up with a solution but it does not really work for me.
https://www.benday.com/2017/03/17/deploy-entity-framework-core-migrations-from-a-dll/
I had to make few modifications to the script in order to set the dll paths right.
Here is how it is looking now
set EfMigrationsNamespace=%Dummy.WebAPI
set EfMigrationsDllName=%Dummy.WebAPI.deps.dll
set EfMigrationsDllDepsJson=%Dummy.WebAPI.deps.json
set EfMigrationsStartupAssembly=%Dummy.Data.dll
set DllDir=%cd%
set PathToNuGetPackages=%USERPROFILE%\.nuget\packages
set PathToEfDll=%PathToNuGetPackages%\microsoft.entityframeworkcore.tools\1.1.1\tools\netcoreapp1.0\ef.dll
ECHO %PathToEfDll%
dotnet exec --depsfile .\%EfMigrationsDllDepsJson% --additionalprobingpath %PathToNuGetPackages% %PathToEfDll% database update --assembly .\%EfMigrationsDllName% --startup-assembly .\%EfMigrationsStartupAssembly% --project-dir . --content-root %DllDir% --data-dir %DllDir% --verbose --root-namespace %EfMigrationsNamespace%
However the script throws index oput of bound error which is very confusing to me. Here is the exception.
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.ParseOption(Boolean isLongOption, CommandLineApplication c
ommand, String[] args, Int32& index, CommandOption& option)
at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(String[] args)
at Microsoft.EntityFrameworkCore.Tools.Program.Main(String[] args)
Index was outside the bounds of the array.
Any clue to this error? Or if I should take any other approach?
It seems that the dotnet exec command is not build correctly, seeing as it has problems parsing your commands.
I'm using dotnet core 2-preview and had to change the batch file slightly. I now works for me:
set EfMigrationsNamespace=%1
set EfMigrationsDllName=%1.dll
set EfMigrationsDllDepsJson=%1.deps.json
set DllDir=%cd%
set PathToNuGetPackages=%USERPROFILE%\.nuget\packages
set PathToEfDll=%PathToNuGetPackages%\microsoft.entityframeworkcore.tools\2.0.0-preview2-final\tools\netcoreapp2.0\ef.dll
dotnet exec --depsfile .\%EfMigrationsDllDepsJson% --additionalprobingpath %PathToNuGetPackages% %PathToEfDll% database update --assembly .\%EfMigrationsDllName% --startup-assembly .\%EfMigrationsDllName% --project-dir . --data-dir %DllDir% --verbose --root-namespace %EfMigrationsNamespace%
I've just used a large part of the day figuring this one out.
Here is the problem: Being used to use MSTest in Bamboo and it works fine.
The first project using Asp.Net.Core, with XUnit tests comes along, and needs to be setup in Bamboo.
Bamboo doesn't support XUnit test result xml files.. Sigh...
What to do?
After upgrading to .Net Core SDK 1.1.1 final bits, this is much easier achived.
Executing the below will execute test, and generate a trx output.
dotnet test --logger trx
Alternatively to determine filename as well
dotnet test --logger "trx;LogFileName=myTestResults.trx"
After a lot of fiddling around this here is the recipe I used.
Execute tests as usual, output result to xml file
dotnet test .\MyProject\test\UnitTests -xml .\TestResults\UnitTests.xml
Run the output xml through an XSLT conversion and convert to MsTest trx format
$xml = Process-XSLT $PSScriptRoot\TestResults\UnitTests.xml $PSScriptRoot\BuildScripts\XUnitToMsTest.xlst
And here comes the culprit. Ensure the TRX xml files is written as UTF-8 - not an ascii file. Tried for hours to figure out why Bamboo wouldn't pick up the test files - until I realized this.
Out-File -FilePath $PSScriptRoot\TestResults\UnitTests.trx -InputObject $xml -Encoding UTF8
Sources:
XUnit to TRX : https://github.com/deloitte-solvas/XSLT-xUnit-To-Trx
ProcessXSLT : https://gist.github.com/wschwarz/5073004 (Had a few bugs)
Entire source to my own ProcessXSLT:
function Process-XSLT([string]$inputFile, [string]$xsl)
{
$fileStream = New-Object -TypeName System.IO.FileStream($inputFile, [System.IO.FileMode]::Open, [System.IO.FileAccess]::Read);
$fileStream.position = 0
$xml = new-object System.Xml.XmlTextReader($fileStream)
$output = New-Object System.IO.MemoryStream
$xslt = New-Object System.Xml.Xsl.XslCompiledTransform
$arglist = new-object System.Xml.Xsl.XsltArgumentList
$reader = new-object System.IO.StreamReader($output)
$xslt.Load($xsl)
$xslt.Transform($xml, $arglist, $output)
$output.position = 0
$transformed = [string]$reader.ReadToEnd()
$reader.Close()
return $transformed
}
When all of the above is done correctly, all left to do is to add a MSTest Parser task to your Bamboo build, pointing at the TestResults folder.
https://confluence.atlassian.com/bamboo/mstest-parser-289277057.html
I hope I save someone else a few minutes with this post.
Bamboo was absolutely no way near telling me the files was invalid - it just stated that no results could be picked up. :-)
Best regards
/Anders
I am following this blog:
http://maplekeycompany.blogspot.se/2012/03/very-basic-cowboy-setup.html
In short, I am trying to compile an application with rebar just as the person in the blog.
Everything goes smoothly until I want to run the command:
./rebar get-deps compile generate
This then give me the following errors and warnings,
> User#user-:~/simple_server/rebar$ ./rebar get-deps compile generate
> ==> rebar (get-deps)
> ==> rebar (compile) Compiled src/simple_server.erl Compiled src/simple_server_http.erl src/simple_server_http_static.erl:5:
> Warning: behaviour cowboy_http_handler undefined Compiled
> src/simple_server_http_static.erl
> src/simple_server_http_catchall.erl:2: Warning: behaviour
> cowboy_http_handler undefined Compiled
> src/simple_server_http_catchall.erl WARN: 'generate' command does not
> apply to directory /home/harri/simple_server/rebar Command 'generate'
> not understood or not applicable
I have found a similar post with the same error:
Command 'generate' not understood or not applicable
I think the problem is in the reltool.config but do not know how to proceed, I changed the path to the following: {lib_dirs, ["home/user/simple_server/rebar"]}
Is there a problem with the path? How can rebar get access to all the src files and also the necessary rebar file to compile and build the application?
You need to make sure your directory structure and its contents are arranged so that rebar knows how to build everything in your system and generate a release for it. Your directory structure should look like this:
project
|
-- rel
|
-- deps
|
-- apps
|
-- myapp
| |
| -- src
| -- priv
|
-- another_app
The rel directory holds all the information needed to generate a release, and the apps directory is where the applications that make up your project live. Application dependencies live in the deps directory. Each app such as myapp and another_app under the apps directory can have their own rebar.config files. While two or more such applications are possible here, normally you'd have just one and all others would be dependencies.
In the top-level project directory there's also a rebar.config file with contents that look like this:
{sub_dirs, ["rel", "apps/myapp", "apps/another_app"]}.
{lib_dirs, ["apps"]}.
If necessary, you can use rebar to generate your apps from application skeletons:
cd apps
mkdir myapp another_app
( cd myapp && rebar create-app appid=myapp )
( cd another_app && rebar create-app appid=another_app )
If an application has dependencies, you'll have to add a rebar.config to its directory and declare each dependency there. For example, if myapp depends on application foo version 1.2, create apps/myapp/rebar.config with these contents:
{deps,
[{foo, "1.*", {git, "git://github.com/user/foo.git", {tag, "foo-1.2"}}}]
}.
When you run rebar get-deps, rebar will populate the top-level deps directory to hold all dependencies, creating deps if necessary. The top-level rebar.config can also declare dependencies if necessary.
You also need to generate a node, necessary for your releases:
cd ../rel
rebar create-node nodeid=project
You then need to modify the reltool.config file generated by the previous step. You need to change
{lib_dirs, []},
to
{lib_dirs, ["../apps", "../deps"]},
and just after the line {incl_cond, derived}, add {mod_cond, derived}, so that releases contain only the applications needed for correct execution.
Next, wherever the atom 'project' appears, you need to replace it with the applications under the apps directory. For our example, we'd change this part:
{rel, "project", "1",
[
kernel,
stdlib,
sasl,
project
]},
to this:
{rel, "project", "1",
[
kernel,
stdlib,
sasl,
myapp,
another_app
]},
and change this part:
{app, project, [{mod_cond, app}, {incl_cond, include}]}
to this:
{app, myapp, [{mod_cond, app}, {incl_cond, include}]},
{app, another_app, [{mod_cond, app}, {incl_cond, include}]}
You might also need to add the line:
{app, hipe, [{incl_cond, exclude}]},
to exclude the hipe application since sometimes it causes errors during release generation or when trying to run the release. Try without it first, but add it if you see errors related to hipe when generating a release, or if attempts to run the generated release result in this sort of error:
{"init terminating in do_boot",{'cannot load',elf_format,get_files}}
you'll need to add it.
With all this in place you can now execute:
rebar get-deps compile generate
and you should be able to successfully generate the release. Note that running rebar generate at the top level rather than in the rel dir will result in a harmless warning like this, which you can ignore:
WARN: 'generate' command does not apply to directory /path/to/project
Finally, you can run the release. Here's how to run it with an interactive console:
$ ./rel/project/bin/project console
Exec: /path/to/project/rel/project/erts-6.2/bin/erlexec -boot /path/to/project/rel/project/releases/1/project -mode embedded -config /path/to/project/rel/project/releases/1/sys.config -args_file /path/to/project/rel/project/releases/1/vm.args -- console
Root: /path/to/project/rel/project
Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:8:8] [async-threads:10] [kernel-poll:false]
Eshell V6.2 (abort with ^G)
(project#127.0.0.1)1>
or you could run ./rel/project/bin/project start to start it in the background. Run ./rel/project/bin/project with no arguments to see all available options.