-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
False positive mutant in Angular controller #151
Comments
Hmm this indeed should not happen. Can you confirm that your test did ran for that mutant? Stryker performs analysis on code coverage. A bug there might result in this test not being ran for the mutant. To see this, please run stryker with the |
Running
|
Using |
Could you change your loglevel to debug ( |
It's among the untested ones:
If you want to locally reproduce this problem, just clone http://github.com/bkimminich/juice-shop and execute |
Thanks @bkimminich! That will be a huge help! I'm on a small vacation and will take a look at it soon as I get back, if @simondel doesn't fix it first that is. |
When Stryker selects tests for a mutant, it looks at which tests cover the smallest statement surrounding the mutated code. We do it this way because a mutation may be smaller than exactly one statement. If a test covers the smallest statement, we decide that it should be ran when testing the mutant. So, what happens in this case? $scope.showDetail = function (id) {
$uibModal.open({
templateUrl: 'views/ProductDetail.html',
controller: 'ProductDetailsController',
size: 'lg',
resolve: {
id: function () {
return id
}
}
})
} and you would expect that the smallest statement would be pretty much the entire piece of code above but... Stryker thinks that the smallest statement in this case is : return id None of the tests cover this return statement (as shown by the actual regular code coverage report) so Stryker marks the mutant as untested. Something goes wrong in the MutantRunResultMatcher's findSmallestCoveringStatement function or one of the functions it calls. |
Testing in the MutantRunResultMatcher for this mutant can be done with this if-statement:
|
Hmmm i was thinking that the smallest statement algorithm was the one to blame for this bug. Even if We should add these examples as test cases to the test suite of the @bkimminich thanks again for the example. |
So back in june we changed the way we mutate code and store the information about the mutation (represented by the mutant class). This forced us to change the let mutantIsAfterStart = mutant.location.start.line > location.start.line ||
(mutant.location.start.line === location.start.line && mutant.location.start.column >= location.start.column);
let mutantIsBeforeEnd = mutant.location.end.line < location.end.line ||
(mutant.location.end.line === location.end.line && mutant.location.end.column <= location.end.column); * I haven't thoroughly tested if this doesn't break anything else. It just fixes this bug and this code makes sense. It actually checks if the mutant starts after the start of the statement and if it ends before the end of the statement. @bkimminich FYI Stryker now reports the following on your codebase:
The drop in the mutation score for covered code is caused by the fact that 2 more mutants survived. We'll have to take a look to see if those mutants should have survived or not. |
@bkimminich we just released Stryker 0.4.4 with the fix. Can you confirm that this issue is now solved? |
I have this code in an Angular 1.x controller:
My original test simply did
expect($uibModal.open).toHaveBeenCalled
which lets this mutant survive:$scope.showDetail = function (id) {}
.Performing this mutation manually yields a failing test:
I even extended my test to be more specific about the expected modal dialog:
expect($uibModal.open).toHaveBeenCalledWith({ templateUrl: 'views/ProductDetail.html', controller: 'ProductDetailsController', size: jasmine.any(String), resolve: { id: jasmine.any(Function) } })
The mutant
$scope.showDetail = function (id) {}
still survives. How is that possible?The text was updated successfully, but these errors were encountered: