I'm using xUnit + NCrunch. I've got some tests marked as integrational:
[Trait("Category", "Integration")]
How do I skip those tests in NCrunch? The tests are not in the separate assembly so I cannot ignore the entire assembly completely.
Related
I use Maven to build a multi-component project. One of the components is a web app with HTML and JavaScript. Maven invokes NPM and Karma to run that component's unit and integration tests, written in QUnit. This yields two independent Cobertura coverage reports that I then combine into one with istanbul-combine.
As a final step, I'd like the Maven build to fail if that combined Cobertura report doesn't satisfy my coverage requirements. But how?
I've tried the Cobertura Maven Plugin, but it seems to be unfit to simply read an existing report and apply its check configuration. First, it needlessly repeats the build's tests ("Invokes the execution of the lifecycle phase test prior to executing itself."), then it finds that it cannot instrument the non-Java resources, then it simply stops, without any log output whatsoever.
Are there other plugins that fit? Could changing the report format help? (Doesn't have to be Cobertura.)
We are running unit tests and acceptance tests in Teamcity, both for Java for the same project. Both generate a test coverage report using JaCoCo.
Is there a way to merge the test coverage reports, so that we can see what code is not covered by either suite?
The coverage report is already published as a hidden artifact after each build. It would need to be imported to the acceptance tests step and referenced by maven, as of this:
http://www.eclemma.org/jacoco/trunk/doc/merge-mojo.html
I'd like my tests to be in a separated project from the code under test as described in Jasmine in a separate test project. However, the approach with including reference paths in the test files doesn't apply to when the test is used with requirejs. Is there any other way to accomplish this?
You should be able to do that using the chutzpah.json file settings. Take a look at this sample which shows having the source and tests in different folders.
I'm using a naming convention for my test assemblies:
AssemblyOne.Tests.dll
ProjectTwo.AssemblyTwo.Tests.dll
...
I'm trying to exclude the assemblies from coverage with the pattern in mstest runner with dotCover:
Assemblies Filter:
-:*.Tests.dll
I does not work, as i see coverage for the test methods in the test assemblies.
Please suggest a setting that would work. Thanks
Assemblies filter accepts assembly names, not dll file names.
For example, instead of -:*.Tests.dll you need to specify:
-:*.Tests
I have a unit test which depends on some code that uses MEF. When I run the test, MEF (I believe) MEF tries to load all dependent DLLs for all the DLLs in the unit test's executing directory.
The problem is that VS2010 for some reason isn't copying all the DLLs from the /bin/debug directory to the unit test's executing directory, and I don't know why. Here's an example:
Unit test is complaining is can't load assembly A, so I include project B which assembly A has as a dependency. In the /bin/debug folder for the unit test project, all the DLLs are in there, but when I look at the unit test's executing directory, assembly A isn't there.
I could start adding DLLs as refs to the unit test project one by one, but I feel like I should have to.
Thoughts?
thanks,
Mark
Maybe the DeploymentItem attribute can help, http://msdn.microsoft.com/en-us/library/ms182475.aspx:
For the parameter of the DeploymentItem attribute, specify the folder
or file that you want to deploy for this test. You can use either an
absolute path or a relative path. Relative paths are relative to the
RelativePathRoot setting found in the .testrunconfig file.
[TestMethod]
[DeploymentItem("MyTestProject\\testdatasource.mdb")]
public void TestMethod1()
{
// TODO: Add test logic here
}
You can add the project as a reference and it will sort it out.
Right click add ref project tab.
Dont ref the dll itself in teh bin\debug folder.
As test projects are simply extensions of the production code, it's not uncommon to share the same dependencies. In some cases, excluding a dependency may compile fine but will fail when the code under test tries to load a missing dependency at runtime (as you've discovered). If your tests however have to use a dependency in the test code, you'll find that you won't be able to compile without referencing that dependency.
Also keep in mind that when you execute a TestRun with MSTest, it's not the compilation process that copies the assemblies -- there's a post compilation step that copies the dependencies for the tests to a specialized "test run" folder, typically under TestResults. Visual Studio supports a feature called "Test Deployment" that can copy additional test data, etc to the test run.
The other element at play here may be the dynamic composition nature of MEF. One of the key benefits of MEF is that it follows a plugin model that dynamically loads assemblies into your application at runtime: simply drop in new assemblies and MEF will pick them up. As such, it's common that the design of the main application will not have direct references to these dynamically loaded assemblies. If you're using MEF in your tests to dynamically load tests, these tests must be copied (using Test Deployment) or referenced as part of the test project.