I'm creating some unit tests with Jasmine and the test runner I'm using is Karma.
I'm also checking the code coverage of these test specs with the karma-coverage plugin.
I was wondering if there's any way of excluding certain functions from the code coverage itself and also from the Karma report (Istanbul actually).
I'm thinking that if the first one is solved then so is the second.
Pretty sure there's no obvious way of doing this, as I've looked in Istanbul as well (karma-coverage uses it) but maybe some of you run into this before.
It appears that the guy behind Istanbul has added support for ignoring specific sections of code from coverage analysis. Really useful!
More here: https://github.com/gotwarlost/istanbul/blob/master/ignoring-code-for-coverage.md
Use below lines of code to ignore code for coverage.
/* istanbul ignore if */ ---skips the "if thing" in the source code
/* istanbul ignore else */ ---skips the "else thing" in the source code
/* istanbul ignore next */ ---skips the "next thing" in the source code
Sometimes you want to ignore testing of the framework itself that you are currently using. That is typically the main reason for my need of this kind of functionality.
Is that function actually being used? If not, you can comment it or remove it completely. But if there's a reason for this function, then let the code coverage results point you out that this function is not tested!
Otherwise, could you put this particular function in it's own file and exclude this file from istanbul?
Related
my only coworker used the following code execution to compile code to pdf
compile to pdf (1st time): produce a first draft version and an .xlsx. but the only purpose is to create the .xlsx.
compile the same file to pdf (2d time): look up in the previously created .xlsx to produce the pdf
To have the process in one pass, simplified and avoid a source of foreseeable bugs (2 pass compilation... hell), I mentioned that we could:
reorganize the code
use 'in-line' code functionality (code in the latex area)
his answer was something like
well it works if you follow the step I describe so no need to change
it and it is written in the comments that you have to compile it twice.
I had to take the time to write the step on a paper. We let non-programmer run this code to produce reports. They don't read comments.
if I refactor the code he will really be upset, because it is not the way he started with plus as mentionned it works if you follow his instruction.
did you already faced it. how did you resolved it?
thanks
When we are coding it is really important to maintain our code base while preserving coding standards. There are plenty of code formatting tools which are matched with the respective IDE. By using them we can format our code while preserving line indentation. So is there any tool to measure that usage of a code formatting in our code base. I already heard there are some tools to measure the test coverage. There that tool gives a percentage of test cases for actual methods in the code. By using that tool we can find the places where we do not implement test cases. Like that I want to catch the places where I do not use the code formatting. When code base has so many source files and number of lines, it's a tedious task to test if we were forgotten to run the code formatting tool. As I know there's no way to run the tool in all the files at once. So guys, if you know a solution to my problem please let me know.
As the title says, I would like to run a single test, not the whole spec. The naive way I tried was using a case like this:
describe("MyCase",function() {
it("has a test",function() {
expect(something).toBe(something);
}
it("has another test",function() {
expect(something_else).toBe(something_else);
}
}
This is saved in a file called MyCase.spec.js (if this matters). I would have thought that it would be possible to run just the first case using the following from the command line:
jasmine-node --match="MyCase has a test"
But this is apperantly not the way to do it. So how is it done?
Thanks!
it may be pretty old channel but it would help someone who is looking for running specific testcase with jasmine 2.0. Use "fdescribe" to run a specific suite and use "fit" to run a specific spec.This skips all other tests except marked.
keep an eye and not to commit fdescribe and fit to repo. Here f describe the "focus".
For lower versions we can use ddescribe, iit as described in upper answers.
Change it with iit and run your test as usual.
Thus only this test will be run and all others will be ignored.
E.g.
iit('should run only this test', function () {
//expect(x).toBe(y);
});
The same works for the describe block, just rename it to ddescribe
Also you can ignore a single it test by renaming it to xit
And xdescribe works too
Not sure if it is applicable for jasmine-node, but using ts-node and Jasmine's node modules path, I can use the filter flag to match the spec's string. For me it looks like:
ts-node node_modules/jasmine/bin/jasmine --filter="employees*"
This would match all the 'it' blocks within a 'describe' block that begin with 'employees'.
It might not be what you need exactly, but I would like to propose using karma / karma-jasmine.
Within Karma, Jasmine is "patched" and provides additional ddescribe and iit methods. If you rename one of your suites to ddescribe or one of your specs to iit (takes precedence over ddescribe), only this suite or spec will be executed. Concerning your question, you could rename your first spec to iit and then only this spec would be executed. Of course, this is only useful while developing the spec.
A downside on this is, that one can easily end up having only a fraction of one's test suites being tested for a long time. So don't forget to rename it back to the usual version (no double d's, no double i's).
Can Anyone point Me to a tool to detect unused code, objects, methods, parameters, etc., in Ruby code?
I saw nitpick but it does not seem to give me the coverage I want. I also checked laser and reek but their respective gems seem to have issues which prevent them from running.
I thought at one point the Ruby binary had a mode which would detect unused constructs but I do not seem to be able to find it.
It might help if we had a little more context in how you want to "detect unused code" - is this code coverage of your tests you're looking into? Otherwise, how would you know from run to run whether you hit all the use cases? Or are you looking for a statistical "heat map" of coverage over time for e.g. performance reasons?
In any case, for code coverage while testing I use SimpleCov - it uses Ruby 1.9's built-in Coverage library with some nice sugar on top.
You can also use a mutation tester that mutates your code. In case the mutation tester can delete a construct without your tests noticing. You found an unused construct.
I know two mutation testers for ruby:
Heckle
Mutant
Disclaimer, I'm the author of mutant.
Depending on your setup, your ruby version, spec layout, test framework heckle and or mutant can do the job for you.
Here you can see mutant in action: http://ascii.io/a/1707
JetBrains RubyMine http://www.jetbrains.com/ruby/quickstart/index.html
With test/unit, and minitest, is it possible to fail any test that doesn't contain an assertion, or would monkey-patching be required (for example, checking if the assertion count increased after each test was executed)?
Background: I shouldn't write unit tests without assertions - at a minimum, I should use assert_nothing_raised if I'm smoke testing to indicate that I'm smoke testing.
Usually I write tests that fail first, but I'm writing some regression tests. Alternatively, I could supply an incorrect expected value to see if the test is comparing the expected and actual value.
To ensure unit tests actually verify anything a technique called Mutation testing is used.
For Ruby, you can take a look at Mutant.
As PK's link points out too, the presence of assertions in itself doesn't mean the unit test is meaningful and correct. I believe there is no automatic replacement for careful thinking and awareness.
Ensuring the tests fail first is a good practice, which should be made into a habit.
Apart from the things you mention, I often set wrong values in asserts in new tests, to check that the test really runs and fails. (Then I fix it of course :-) This is less obtrusive than editing the production code.
I don't really think that forcing the test to fail without an assert is really helpful. Having an assert in a test is not a goal in itself - the goal is to write useful tests.
The missing assert is just an indication that the test may not be useful. The interesting question is: Will the test fail if something breaks?. If it doesn't, it's obviously useless.
If all you're testing for is that the code doesn't crash, then assert_nothing_raised around it is just a kind of comment. But testing for "no explosions" probably indicates a weak test in itself. In most cases, it doesn't give you any useful information about your code (because "no crash != correct"), so why did you write the test in the first place? Plus I rather prefer a method that explodes properly to one that just returns a wrong result.
I found the best regression test come from the field: Bang your app (or have your tester do it), and for each problem you find write a test that fails. Fix it, and have the test pass.
Otherwise I'd test the behavior, not the absence of crashes. In the case that I have "empty" tests (meaning that I didn't write the test code yet), I usually put a #flunk inside to remind me.