I am unable to find a way how to run code coverage in STS4.
In Eclipse Oxygen, I needed to do:
Right-click on project > Properties > Coverage to enable code
coverage
Then, right-click on project > Run Code Coverage
However, both of these 2 options are missing in STS4
There is no code coverage feature installed by default in the Spring Tools 4 for Eclipse distribution (and never was, as far as I remember), but you might have had an Eclipse installation with such a third-party plugin installed. Maybe installing this from the marketplace helps:
marketplace.eclipse.org/content/eclemma-java-code-coverage
For future readers, if you don't find the tool "EclEmma Java Code Coverage" in Eclipse Marketplace, search it through the other setup menu : Help > Install New Software...
Installation's official guide: https://www.eclemma.org/installation.html.
Related
Is it possible to analyze C# project using Sonar-runner with sonar-c#-plugin-4.2. I saw the MSBuild SonarQube Runner to be used for C# analysis on the documentation.
Does sonar-runner support C# analysis on sonarqube 5 with C# 4.2
The use of the sonar-runner is no longer supported to analyze C# projects. Indeed, analysis through the MSBuild SonarQube Runner will be of much higher quality because it fully integrates with MSBuild and knows everything about your project, and at the same time also much easier to setup, again because most manual configuration required before is now obtained through MSBuild itself.
At least I managed to run the analysis with the sonar-runner. I consider the new begin-build-end workflow with MSBuild SonarQube Runner a bit complicated while using Jenkins and having plenty of existing scripts in play at least. Or I could not get it working due to slightly TFS-oriented documentation with Visual Studio command prompt being also involved.
I finally, after intensive googling, got the analysis running with my Visual Studio Pro + Jenkins + OpenCover + Mstest + Nunit combination by defining below properties in Invoke Standalone SonarCube Analysis in Jenkins job. I still do not know how to separate integration tests from unit tests. It does not say anywhere is this even supported for C# projects.
Workflow is that I first build everything, then run OpenCover to collect results with coverage and then invoke the runner. The below properties can of course be as file in the root folder of the project as well, but in my initial proof of concept I set these in Jenkins plugin.
sonar.projectName=projectname
sonar.projectKey=key
sonar.ProjectVersion=1.1
sonar.visualstudio.enable=true
sonar.language=cs
sonar.sources=.
sonar.dotnet.visualstudio.solution.file=code.sln
#not sure if the line below is correct or relevant...
sonar.dotnet.visualstudio.testProjectPattern=*Test
#two frameworks producing tests.
sonar.cs.vstest.reportsPaths=relativepath/results.trx
sonar.cs.nunit.reportsPaths=relativepath/testresults.xml
sonar.cs.opencover.reportsPaths=1.xml,2.xml
I want to debug code written in C. Currently, Android Studio 1.2.2 does not seem to support JNI debugging.
Does Android Studio 1.3 RC 1 version support step over, step into as Java debugger?
Android Studio supports JNI debugging first time with 1.3 RC 1. See here
To get started using this feature, go to add native code.
Check this repository for Android NDK samples using the new Android Studio 1.3 preview C++ integration.
It is supported, but with limitations.
Limitations
First, the Android NDK support only works with the new experimental Gradle plugin for Android (which in turn requires Gradle 2.5).
While the new gradle plugin delivers some major performance improvements (and Android NDK build support), note that it also requires changes to the build file “DSL” (the way your build is described in your build.gradle files.) Not only will you need to modify your build.gradle files (a process we hope to automate before the plugin graduates from experimental to stable), but we anticipate making some additional incompatible changes along the way.
Second, note also that Android Studio has not yet been updated to fully handle the experimental plugin. This means that for example the Project Structure Dialog, and various quick fixes which automatically update the build data, do not work correctly. You’ll need to edit your build.gradle files manually to configure your projects. As another example, the various templates which update the build files (such as New Module), have not yet been updated.
Finally, there are still some known bugs in this build; when debugging with LLDB breakpoints do not always work on Windows; if you run into this, you can switch to GDB debugging as a temporary workaround.
Source: http://tools.android.com/tech-docs/android-ndk-preview
If your native code is wrapped as a library, you need to add this part to your app's gradle:
model {
android.sources {
main {
jniLibs {
dependencies {
project ":mynativelib" buildType "debug"
}
}
}
}
I have a Visual Studio solution consisting of several projects. I set a build process for it in TeamCity, and I have added a an NUnit runner build step, with these settings:
nunit runner 2.6.3
run tests from: %teamcity.build.workingDir%\Sources\**\bin\*.Web.UnitTests.dll
.net coverage tool: JetBrains dotCover
Filters: --empty--
In the Code Coverage tab of the build, under Coverage Breakdown, I can only see:
MyProject.Domain
MyProject.Web.UnitTests
MyProject.Web, the object of the tests, and a few other assemblies in the solution are not displayed there, and are ignored by the dotCover code coverage calculations. Why? How can I tell it which assemblies to use?
I've unsuccessfully tried various +: / -: combinations in the Filters field. But with Filters empty, I am expecting MyProject.Web to be included, since MyProject.Domain is - why isn't it included?
Are you building in Release or Debug mode? I had the same problem with Release mode and had to enable PDB output which is what dotCover requires to determine the code coverage. PDB is not enabled by default for Release builds.
To enable it go to Project Settings -> Build -> Advanced (button at the bottom) -> Debug Info -> Choose "pdb-only" or "full".
Additionally, dotCover provides this statement when no code coverage can be determined. It may be helpful to check all of the reasons listed:
No executable code was detected.
The issue could be caused by one of the following:
Include / exclude patterns are incorrect
Assemblies are compiled without debugging information
.pdb files are not available
Visual Studio code coverage is enabled for MSTest
.testrunconfig is used for MSTest and Visual Studio code coverage is not disabled (CodeCoverage section with enable="true" is present)
I'm afraid without log files and your snapshot it will be difficult to provide the right answer. Please submit a request and attach the files: http://dotnettools-support.jetbrains.com/anonymous_requests/new
If logs are not enabled yet, add the corresponding parameter to your build configuration to activate them: https://confluence.jetbrains.com/display/TCD9/Reporting+Issues#ReportingIssues-dotCoverIssues
Trying to debug an NUnit test in VS2010 and is not stopping on the breakpoint. It was working the last time I tried need to debug the test (maybe 1 yr ago) but now it doesn't work.
I've tried the following:
How to debug with vs.net 2008 and nunit?
http://erraticdev.blogspot.com/2012/01/running-or-debugging-nunit-tests-from.html
I've tried attaching, rechecking my installation, updated the config file so it's using the 4.0 runtime, still doesn't hit the breakpoint.
What am I missing?
You can debug nunit tests in VS studio community version only. For this you need to install Nunit3testAdpter. You can add this in Tools -> Extension and updates. or from Nuget packages.
This is a long overdue question but I haven't seen the solution to debug NUnit tests directly within Visual Studio. This is quite easily possible and without any third party tools. All you have to do is configure your test project (which is just a plain old Class library project) so it will start NUnit test runner whenever you hit F5 or Ctrl-F5 (just run, no debugging).
Particularly you will have to configure your project properties to start an external program:
Step by step configuration is very well described in this blog post. It advises you to use NuGet to obtain NUnit test runner and configure project to execute the runner when you try running your library project. As simple as that. Using no specific tools which are usually not free.
There are multiple reasons why this may happen. If your application's target framework is different from NUnit's, then you won't be able to debug, because the tests are actually being run by nunit-agent.exe.
For me, my application was using 4.5, but NUnit's was using 3.5. (You can find this from one of the NUnit GUI applications -> Help -> About)
To fix this, change the nunit.exe.config file to include the following, inside the configuration section:
<startup>
<requiredRuntime version="4.0.30319" />
</startup>
This can also happen when your PDB generation is set to embedded. Switching it to full will allow the nunit test adapter to start with the debugger attached. At that point it can be switched back to embedded and it will debug again.
The setting is on the project properties pages, in the Build tab, then click the Advanced button. I always choose "All Configurations" at the top, so I make sure I'm emitting a useful PDB (or embedding the info) when building Release configuration assemblies too.
The other day I failed to hit a breakpoint in my NUnit debugging. It took me a while to realize that someone had copy/pasted the test into a different file and I was running a different test than the one that the breakpoint was in.
I recently had a similar problem. Changing the project's platform to AnyCPU solved it for me. Also worth checking:
1) Check NUnit's latest version (I was using 2.5.7, updated to 2.6.2)
2) The Target Framework for your test project. I was using .NET 4.0 (you can find it under Properties -> Application, on VS2010)
At least up to vs2010 the debugger can only debug 32 bit apps but not 64 bit apps.
With vs2010 I am using a 32bit nunit.exe version and use "attach to debugger". This workes well for me.
Please upgrade NUnit Test Extension and close the Visual studio so Visx (probably spell) will run and update NUnit tool.
After this you can open your project and run NUnit test project.
It will run.
I tested accurately.
Try changing the test to x64. From the menu do
Test -> Test Settings -> Default Processor Architecture -> x64.
i think u cant debug with Visual studio. better u install TestDriven.NET.
then
Put the BreakPoint on the test method
Right click on the test
method.
select TestWith->Debugger
I'm beginning to get the grips of BDD and MSpec, but I'm still really bugged by the fact that I'm unable to debug my tests/specs, and that I have to leave the IDE to go to a html report file to see the results.
Currently, I have a post build event configured to run mspec.exe $(TargetFileName) --html “$(ProjectDir)Report.html”, but there must be some better way to do this.
Does anyone know any good add-ins, test runners or whatever that will let me
debug tests, instead of just running them
show the test results in a nice way inside Visual Studio
(Footnote: I'm running VS2010 Professional on Windows 7, if that matters.)
There are basically three options you have:
You can set up a custom tool in
Tools | External Tools to start
mspec.exe with the current project's
assembly to run the contexts and
generate the HTML report.
Install TestDriven.Net and
ensure that
Machine.Specifications.dll.tdnet
and
Machine.Specifications.TDNetRunner.dll
are in your project's copy of MSpec.
You can then run and debug your
contexts from the context menu: "Run
Tests", "Run With | Debugger" without further installation.
There's an example of what the MSpec folder
looks like for all of my projects.
If you use ReSharper 4.1, 4.5, 5.0
or the latest 5.1 EAP (== beta)
there are runners for each of these
versions.
The ZIP download
contains batch files that install
the runner for each respective
version of ReSharper. ReSharper's
unit test support is pretty
extensive in terms of UI
widgets/shortcut support, the reporting
tree view and debugging.
If you're
a dotTrace user you can also profile
right from within Visual Studio.
dotCover (another JetBrains product)
allows you to calcualate code
coverage results from your MSpec
runs.
On top of that, you get
all the nice coding and navigation features that ReSharper provides.
Be aware that only the first option will generate the HTML report as both the TestDriven.Net and ReSharper runners do not support HTML report generation. From my point of view this isn't an issue since the TD.Net and ReSharper runners offer fairly complete reporting mechanisms through the Visual Studio UI.
Another option that might work (I haven't used it myself) is to leverage the Gallio support that MSpec has. Gallio is a runner/framework for several testing frameworks; it might as well support debug runs with MSpec. Contact #smaclell if you have questions about Gallio support.