Skip to content
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

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

ctlai95
Copy link
Contributor

@ctlai95 ctlai95 commented Jan 9, 2025

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:

  • Severity (existing behavior)
  • File Location (issues in the same file are grouped together)
image image
  • Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
  • Your code changes must meet the guidelines in CONTRIBUTING.md.
  • License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

@ctlai95 ctlai95 marked this pull request as ready for review January 10, 2025 18:07
@ctlai95 ctlai95 requested review from a team as code owners January 10, 2025 18:07

it('should return fallback when stored state is invalid', function () {
const invalidStrategy = 'invalid'
sandbox.stub(globals.globalState, 'tryGet').returns(invalidStrategy)
Copy link
Contributor

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)
Copy link
Contributor

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')
Copy link
Contributor

@justinmk3 justinmk3 Jan 13, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants