-
Notifications
You must be signed in to change notification settings - Fork 480
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
feat(amazonq): grouping options for code issues #6330
base: master
Are you sure you want to change the base?
Conversation
|
||
it('should return fallback when stored state is invalid', function () { | ||
const invalidStrategy = 'invalid' | ||
sandbox.stub(globals.globalState, 'tryGet').returns(invalidStrategy) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not just set the globalState? the tests have a fake globalState, it is safe to set it.
sinon and stubs aren't needed.
const tryGetStub = sandbox.stub(globals.globalState, 'tryGet').returns(undefined) | ||
const result = state.getState() | ||
|
||
sinon.assert.calledWith(tryGetStub, 'aws.amazonq.codescan.groupingStrategy', String) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these kinds of tests are very fragile. can you assert the actual state instead of using stubs/mocks?
}) | ||
|
||
it('should update state on selection', async function () { | ||
const spy = sinon.spy(CodeIssueGroupingStrategyState.instance, 'setState') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use "singletons", which presumably are intended to make modules testable. Do we need to stub the global singleton, or can we create a new singleton "object" for testing?
If not, then there is zero reason to have singletons at all, we might as well use plain old modules.
Problem
Code issues are grouped by severity and while this is useful in some cases, it can be hard to navigate.
Solution
Let the user decide how to group the issues.
Grouping strategies to start off with:
feature/x
branches will not be squash-merged at release time.