In our project we are using Cake to build our project and also I set up dotcover for code covering. I use .WithFilter("-:ExcludeFromCodeCoverage") to filter [ExcludeFromCodeCoverage] attribute in code? but it seems it does not work. Dotcover does not exclude classes with [ExcludeFromCodeCoverage] attribute.
In order to exclude classes with [ExcludeFromCodeCoverage] attribute, please try to use .WithAttributeFilter("System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute").
Related
I am using the output parameter of google test like
--gtest_output=xml:Reports\fooReport.xml
However some XML attributes like author and project won´t be exported as the tool gtest2html might expect.
Is there a property like 'author' available in gtest at all? If so, where would I assign it?
Explanation
In GoogleTest, those fields that you see in gtest2html like 'author', 'project', etc. are not available in the xml output by default. Those are custom field expected to be found by gtest2html.
However, you can add them to the same xml element using RecordProperty function provided by GoogleTest.
The final section of the documentation explains:
Calling RecordProperty() outside of the lifespan of a test is allowed. If it's called outside of a test but between a test suite's SetUpTestSuite() and TearDownTestSuite() methods, it will be attributed to the XML element for the test suite. If it's called outside of all test suites (e.g. in a test environment), it will be attributed to the top-level XML element.
So, in order to make your xml output compatible with gtest2html, you need those fields in the outermost xml element (which has the tag "testsuites").
Solution
So, in main or in a test environment (you don't have to use one, but it is strongly recommended in the documentation), before any test is started, you need to add below call:
::testing::Test::RecordProperty ("project", "MyProject");
This will then add this to the xml output:
<testsuites ... project="MyProject" name="AllTests">
(I know it is quite late as an answer, but hopefully this will help someone)
Without minitest/spec, the test looks like this, and the my_engine_customers fixtures are loaded (all is well):
my_engine/test/models/my_engine/customer_test.rb is
require 'test_helper'
module MyEngine
class CustomerTest < ActiveSupport::TestCase
test "alex is id 5" do
assert my_engine_customers(:alex).id, 5
end
end
end
After adding require 'minitest/autorun' to test/test_helper.rb, and then
converting the above test :
require 'test_helper'
describe MyEngine::Customer do
let(:alex) { my_engine_customers(:alex) } # error here (error shown below)
it "alex is id 5" do
assert alex.id, 5
end
end
I get this error:
NoMethodError: undefined method `my_engine_customers' for
#<#<Class:0x007fb63e8f09e8>:0x007fb63e81b068>
How do I access fixtures when using minitest/spec ?
When you use the spec DSL you get a Minitest::Spec object to run your tests. But the Rails fixtures and database transaction are only available in ActiveSupport::TestCase, or test classes that inherit from it like ActionController::TestCase. So what you need is some way for the spec DSL to use ActionSupport::TestCase for you tests.
There are two steps to this, first ActiveSupport::TestCase needs to support the spec DSL. You can do this by adding the following code to you test_helper.rb file:
class ActiveSupport::TestCase
# Add spec DSL
extend Minitest::Spec::DSL
end
(Did you know ActiveSupport::TestCase.describe exists? You probably want to remove that method before you add the spec DSL if you plan on doing nested describes.)
Second, you need to tell the spec DSL to use ActiveSupport::TestCase. The spec DSL adds register_spec_type for just this purpose. So also add the following to your test_helper.rb file:
class ActiveSupport::TestCase
# Use AS::TestCase for the base class when describing a model
register_spec_type(self) do |desc|
desc < ActiveRecord::Base if desc.is_a?(Class)
end
end
This will look at the subject of the describe and if it is an ActiveRecord model it will use ActiveSupport::TestCase instead of Minitest::Spec to run the tests.
As you might expect, there are lots of other gotchas involved when you try to use the spec DSL for controllers and other types of tests. The easiest way IMO is to add a dependency on minitest-rails and then require "minitest/rails" in your test_helper.rb file. minitest-rails does all this configuration and more and makes the process much smoother. (Again, IMO.)
For more info see my blaurgh post Adding Minitest Spec in Rails 4. </shameless-self-promotion>
I'm using SpringSecurity plugin in my project and also Cobertura plugin for code coverage reports. The thing is I'd like the SpringSecurity specific classes (login and logout controllers, persistent login token and so on) to be excluded from my reports, since I assume they work properly. I'd like reports to contain only my project specific classes code coverage. Is there any way I can achieve that?
coverage {
exclusions = ['**/grails-app/conf/**','**/*any.other.package*','**/*any.class*']
xml = true
enabledByDefault = true
}
Add the above snippet and configure the exclusions list in BuildConfig.groovy in grails-app/conf
Please see Exclude code from code coverage with Cobertura
There is a similar post Excluding some classes from the cobertura report doesn't work, but it is still unresolved.
I have seen the [DebuggerNonUserCode] and [ExcludeFromCodeCoverage] attributes in resources and other SO questions about exlcuding code from coverage statistics, and wanted to know if it was possible to automatically add this attribute to the classes in the code generated by the Entity Framework using .NET 4.0.
Also would it need to be class level or could it be on the diagram.Designer.cs level, needing one attribute for all code generated by that diagram?
Since partial classes (which Entity Framework creates) merge attributes, extended functionality in other partial classes are also excluded if the attribute is class level in the template, it will have to be applied at the method level.
The best way that I've found to do this is using T4 (as recommended in #Craig Stuntz's answer) to:
include: using System.Diagnostics.CodeAnalysis; at the top of the file
Then apply [ExcludeFromCodeCoverage] to getters, setters and Factory methods by searching for:
#>get
#>set
Template_FactoryMethodComment
and placing them in the appropriate place.
This was made a lot easier using Tangible's T4 editor Extension for VS.
This is my first attempt and it seems to work, "your milage may vary", so complete a test run to make sure everything's working as necessary.
Is it possible to have a fixture change between test methods? If so, how can I do this?
My syntax for this problem :
In the cakephp framework i am building tests for a behavior that is configured by adding fields to the table. This is intended to work in the same way that adding the "created"
and "modified" fields will auto-populate these fields on save.
To test this I could create dozens of fixtures/model combos to test the different setups, but it would be a hundred times better, faster and easier to just have the fixture change "shape" between test methods.
If you are not familiar with the CakePHP framework, you can maybe still help me as it uses SimpleTest
Edit: rephrased question to be more general
I'm not familiar specifically with CakePHP, but this kind of thing seems to happen anywhere with fixtures.
There is no built in way in rails at least for this to happen, and I imagine not in cakePHP or anywhere else either because the whole idea of a fixture, is that it is fixed
There are 2 'decent' workarounds I'm aware of
Write a changefixture method, and just before you do your asserts/etc, run it with the parameters of what to change. It should go and update the database or whatever needs to be done.
Don't use fixtures at all, and use some kind of object factory or object generator to create your objects each time
This is not an answer to my quetion, but a solution to my issue example.
Instead of using multiple fixtures or changing the fixtures, I edit the Model::_schema arrays by removing the fields that I wanted to test without. This has the effect that the model acts as if the fields was not there, but I am unsure if this is a 100% test. I do not think it is for all cases, but it works for my example.