Hi G Ann Campbell, the code was fine for years, but Sonarcloud started reporting these false positives since September/October 2023. Now we have 130+ code smells with the same issue. See code example below:
import { createStructuredSelector } from 'reselect';
import sinon from 'sinon';
import * as dummyViewSelector from 'dummy-view-selector';
describe('Modification using dummyViewSelector', () => {
beforeEach(() => {
sinon.spy(dummyViewSelector, 'default');
});
afterEach(() => {
dummyViewSelector.default.restore();
});
describe('dummy view selector', () => {
const dummyViewSelector =
require('dummy-view-selector').select;
const SELECTORS = [
'dummyConfiguration',
'isLoading',
];
it('should call our dummy selector with the original selectors supplied', () => {
// Sonarcloud reports code smell for the line above - Add at least one assertion to this test case.
expect(dummyViewSelector.default.called).toBeFalsy();
dummyViewSelector();
expect(dummyViewSelector.default.calledOnce).toBeTruthy();
expect(dummyViewSelector.default.firstCall.args).toEqual([
createStructuredSelector,
expect.objectContaining(
SELECTORS.reduce(
(_, name) => ({
..._,
[name]: expect.any(Function),
}),
{},
),
),
]);
});
});
The rule you mentioned underwent some modifications recently, specifically to accommodate Sinon.js and Vitest assertion APIs.
It appears these changes resulted in false positives in your case, particularly where youâre utilizing the Sinon.js API for spying purposes. Additionally, your code uses the Jest assertion API, which the current rule doesnât recognize.
Iâve opened a ticket to address this false positive promptly.