How to show test results via command line


I am running the command line via a tfs build. Since dotCover runs all my units tests, I do not want to run them all again using the built in test run in the template.

Is there a way to display the test run results along side the coverage or has anyone done anything similar to this (e.g. find the test run and publish it to the build). I do get a notification of a failure, but I'd like to be able to see the whole test run.

I'm using TFS 2013 Update 4 and mstest.



Alexander Mikhailov
Comment actions Permalink

Hello Jared,

dotCover does not collect test results in console mode. But you may try:
1. Capture stdout. dotCover redirects all output of profiled applications. So if mstest outputs test results in stdout - it will be in dotCover's stdout as well.
2. Add /ReturnTargetExitCode argument to dotCover. By default dotCover returns zero exit code if profiling was successful.
However, if this switch is set - dotCover will return MsTest's exit code. In this case it will be zero if all tests passed and non-zero if some of them failed
3. Depending on a way you are running your tests - you may find additional command line switches for MsTest, that saves/publishes test results. For example: Command-Line options for publishing test results

Comment actions Permalink

Thanks for the response. I managed to work out how to do what I needed myself and am sharing it here in case anyone else needs to to the same. This example is run as a PowerShell script on the post build hook;

# Coverage with dotCover
  $hasTestRunFailed = 0
    Write-Host "Running dotCover"
    $excludedAssemblies = ""
    $splitAssemblies = $dotCoverExcludedAssemblies.Split(' ')
    foreach($assembly in $splitAssemblies)
     $excludedAssemblies = $excludedAssemblies + "-:module=" + $assembly + ";"

    c:\buildtools\dotCover\dotcover.exe cover /TargetExecutable="C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" /TargetWorkingDir="$Env:TF_BUILD_BUILDDIRECTORY\bin" /TargetArguments="$dotCoverTargetArguments /logger:TfsPublisher;Collection=http://tfsserver:8080/tfsinstance/TeamProjectCollection;BuildName=$Env:TF_BUILD_BUILDNUMBER;TeamProject=MyTeamProject;Flavor=Release;RunTitle=$Env:TF_BUILD_BUILDNUMBER" /Filters="$excludedAssemblies"  /Output="$Env:TF_BUILD_BUILDDIRECTORY\CoverageReport.dcvr"
    $hasTestRunFailed = $LASTEXITCODE
    c:\buildtools\dotCover\dotcover.exe report /Source="$Env:TF_BUILD_BUILDDIRECTORY\CoverageReport.dcvr" /Output="$Env:TF_BUILD_BUILDDIRECTORY\CoverageReport.html" /ReportType="HTML"
    c:\buildtools\dotCover\dotcover.exe report /Source="$Env:TF_BUILD_BUILDDIRECTORY\CoverageReport.dcvr" /Output="$Env:TF_BUILD_BUILDDIRECTORY\CoverageReport.xml" /ReportType="XML"

    c:\buildtools\coverage\Tools.Coverage.exe "$Env:TF_BUILD_BUILDDEFINITIONNAME" "$Env:TF_BUILD_BUILDNUMBER" "$Env:TF_BUILD_BUILDDIRECTORY\CoverageReport.xml"

    Copy-Item "$Env:TF_BUILD_BUILDDIRECTORY\CoverageReport" "$Env:TF_BUILD_DROPLOCATION" -recurse
    Write-Host "dotCover report: $Env:TF_BUILD_DROPLOCATION\CoverageReport.dcvr"
    Write-Host "dotCover report: $Env:TF_BUILD_DROPLOCATION\CoverageReport.html"

    Write-Host "Finished running dotCover"

The tool called Tools.Coverage.exe above parses the xml file and saves historical coverage data to a simple database schema to enable us to do historical trending. It also outputs a file that just contains the final coverage figure. I then use an 'InvokeMethod' activity to call System.IO.File.ReadAllText and then I can write the overal coverage figure to the build summary (along with links to the reports) using the WriteCustomSummaryInfiormation activity.

I also forced the PowerShell script to return 1 if the tests fail and added a step to the build to flag it as failed if that is the case.

All together this gives us really good information on the build summary, including the test summary, coverage figure and links to coverage reports. I couldn;t find any way to integrate the dotCover report with TFS, but the custom database is good enough for us to see the historical trends by assembly and overall.




Please sign in to leave a comment.