13

I am trying to figure out how to restrict my tests, so that the coverage reporter only considers a function covered when a test was written specifically for that function.

The following example from the PHPUnit doc shows pretty good what I try to achieve:

The @covers annotation can be used in the test code to specify which method(s) a test method wants to test:

/**
 * @covers BankAccount::getBalance
 */
public function testBalanceIsInitiallyZero()
{
    $this->assertEquals(0, $this->ba->getBalance());
}

If the test above would be executed, only the function getBalance will be marked as covered, and none other.

Now some actual code sample from my JavaScript tests. This test shows the unwanted behaviour that I try to get rid of:

it('Test get date range', function()
{
    expect(dateService.getDateRange('2001-01-01', '2001-01-07')).toEqual(7);
});

This test will mark the function getDateRange as covered, but also any other function that is called from inside getDateRange. Because of this quirk the actual code coverage for my project is probably a lot lower than the reported code coverage.

How can I stop this behaviour? Is there a way to make Karma/Jasmine/Istanbul behave the way I want it, or do I need to switch to another framework for JavaScript testing?

BillyTom
  • 2,519
  • 2
  • 17
  • 25
  • What comes to mind is to use dependency injection and mocks to reduce the number of calls to actual production-code. – henrikmerlander Mar 15 '16 at 14:17
  • I agree with henrikmerlander. Besides, if you're using real function calls instead of mocks inside the tested method indirectly you're testing that function as well – ejosafat Mar 24 '16 at 11:40
  • really good question. For example, testing with phpunit, we have /** @coverage **/ phpdoc tag ;) – pablorsk Jun 10 '18 at 16:05

1 Answers1

2

I don't see any particular reason for what you're asking. I'd say if your test causes a nested function to be called, then the function is covered too. You are indeed indirectly testing that piece of code, so why shouldn't that be included in the code coverage metrics? If the inner function contains a bug, your test could catch it even if it's not testing that directly.

You can annotate your code with special comments to tell Istanbul to ignore certain paths: https://github.com/gotwarlost/istanbul/blob/master/ignoring-code-for-coverage.md but that's more for the opposite I think, not to decrease coverage if you know you don't want a particular execution path to be covered, maybe because it would be too hard to write a test case for it.

Also, if you care about your "low level" functions tested in isolation, then make sure your code is structured in a modular way so that you can test those by themselves first. You can also set up different test run configurations, so you can have a suite that tests only the basic logic and reports the coverage for that.

As suggested in the comments, mocking and dependency injections can help to make your tests more focused, but you basically always want to have some high level tests where you check the integrations of these parts together. If you mock everything then you never test the actual pieces working together.

fabio.sussetto
  • 6,964
  • 3
  • 25
  • 37