Skip to content

feat(compass-collection): Collection Header Experimentation Integration for Mock Data Generator – CLOUDP-333847 #7181

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

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

jcobis
Copy link
Collaborator

@jcobis jcobis commented Aug 8, 2025

Description

Implements the Mock Data Generator button in the Collection Header Actions component. The feature adds a new "Generate Mock Data" button that appears conditionally based on experiment assignment, Atlas environment, and collection type.

Also adds the modal state to the Redux store.

Enabled

Screenshot 2025-08-08 at 3 39 24 PM

Disabled

Screenshot 2025-08-08 at 3 41 45 PM

Motivation and Context

This implements the Mock Data Generator feature integration into the Collection Header, allowing users to access AI-powered mock data generation directly from the collection view. The feature is gated behind an experiment.

  • Bugfix
  • New feature
  • Dependency update
  • Misc

Types of changes

  • Backport Needed
  • Patch (non-breaking change which fixes an issue)
  • Minor (non-breaking change which adds functionality)
  • Major (fix or feature that would cause existing functionality to change)

@Copilot Copilot AI review requested due to automatic review settings August 8, 2025 19:25
@jcobis jcobis requested a review from a team as a code owner August 8, 2025 19:25
@github-actions github-actions bot added the feat label Aug 8, 2025
@jcobis jcobis added the no release notes Fix or feature not for release notes label Aug 8, 2025
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR integrates the Mock Data Generator feature into the Collection Header component. The feature adds a new "Generate Mock Data" button that appears conditionally based on experiment assignment, Atlas environment, and collection type.

  • Adds new experiment test group enum for Mock Data Generator experimentation
  • Implements Mock Data Generator button in Collection Header Actions with conditional visibility
  • Integrates mock data generator modal with collection header state management

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
packages/compass-telemetry/src/provider.tsx Exports experiment test groups and assignment hook for external use
packages/compass-telemetry/src/index.ts Adds ExperimentTestGroup export to public API
packages/compass-telemetry/src/growth-experiments.ts Defines experiment test groups for Mock Data Generator
packages/compass-collection/src/components/collection-header/collection-header.tsx Integrates mock data generator modal state and UI
packages/compass-collection/src/components/collection-header-actions/collection-header-actions.tsx Implements conditional Mock Data Generator button with experiment gating
packages/compass-collection/src/components/collection-header-actions/collection-header-actions.spec.tsx Adds comprehensive test coverage for Mock Data Generator button behavior

@jcobis jcobis changed the title feat(compass-collection): Collection Header Experimentation Integration for Mock Data Generator feat(compass-collection): Collection Header Experimentation Integration for Mock Data Generator – CLOUDP-333847 Aug 8, 2025
trigger={
<div>
<Button
data-testid="collection-header-generate-mock-data"
Copy link

@kpamaran kpamaran Aug 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

data-testid should have a -button suffix or similar

@@ -168,4 +204,182 @@ describe('CollectionHeaderActions [Component]', function () {
);
});
});

context('Mock Data Generator Button', function () {
Copy link

@kpamaran kpamaran Aug 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest adding data-testid for the tooltip and asserting its existence directly in maybe new tests like 'should show Tooltip when ...'

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, how about we add this once we hook up the data so we can test its presence when collection is empty?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good


expect(onOpenMockDataModal).to.have.been.calledOnce;
});
});
Copy link

@kpamaran kpamaran Aug 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be nice to have a test that the modal opens initially with step MockDataGeneratorStep.AI_DISCLAIMER since that is controlled by the header

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: what step we open up to will depend on the state of project level settings, as well as a user-level "opt in" flag. We do have the test should call onOpenMockDataModal when CTA button is clicked, so I think the step we open to will depend based on functionality we will add in later tickets. Do you think this test is sufficient for now, or would you suggest adding something?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's good. No point in adding a test that'd be irrelevant so soon

Copy link

@kpamaran kpamaran left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only had minor feedback around testing. Looks good in general

export enum ExperimentTestGroup {
mockDataGeneratorVariant = 'mockDataGeneratorVariant',
mockDataGeneratorControl = 'mockDataGeneratorControl',
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a small note, it's not a hard-and-fast rule, but we generally have a mild preference for literal unions over enum types – i.e. export type ExperimentTestGroup = 'mockDataGeneratorVariant' | 'mockDataGeneratorControl'; since that has a few small advantages over enums:

  • You don't unnecessarily alias a value to a property name if they're both the same anyway
  • You can often avoid importing and resolving the module at runtime when using enum values, and instead either have a type-only import or none at all
  • Literal unions would be compatible with --erasableSyntaxOnly if we ever decide to adopt this flag
  • Literal unions are also just generally a bit more flexible and can include additional values if we need to add them later, e.g. type Foo = 'abc' | 'def' | `numeric:${number}`;

Copy link
Collaborator Author

@jcobis jcobis Aug 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very good point, I tend to agree. I was following the existing pattern here and I think it might have something to do with how experiments can be iterated on, as in these values can actually change. These values have to correspond to Pholiota values, so for eg. MOCK_DATA_GENERATOR_20251001 can become MOCK_DATA_GENERATOR_20260123 if an experiment iteration is conducted. See the MMS code as well. I am open to changing this though, particularly for ExperimentTestGroup

return await renderWithActiveConnection(ui, connectionInfo);
} else {
// For tests that only need basic component rendering (readonly checks, view buttons, etc.)
const { render } = await import('@mongodb-js/testing-library-compass');
Copy link
Collaborator

@gribnoysup gribnoysup Aug 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this a dynamic import?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consolidated


if (connectionInfo) {
// For tests that need Atlas metadata (Mock Data Generator button visibility, etc.)
return await renderWithActiveConnection(ui, connectionInfo);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just use it for both cases, what difference does it make?

};

const ui = (
<TelemetryProvider options={{ sendTrack: sinon.stub() }}>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

compass-testing-library render helpers already provide default track function, why are you adding this provider?

Comment on lines 340 to 343
expect(
screen.getByTestId('collection-header-generate-mock-data-button')
).to.exist;
expect(screen.getByText('Generate Mock Data')).to.exist;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

get by text is already pretty good, get by role is even better, why do you duplicate this check with get by test id?

Comment on lines 111 to 115
// Mock Data Generator modal state
const [isMockDataModalOpen, setIsMockDataModalOpen] = useState(false);
const [currentStep, setCurrentStep] = useState(
MockDataGeneratorStep.AI_DISCLAIMER
);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that having this as a UI state makes sense: you have form state transitions that clearly would depend on async actions that are handled by the store and reducers and syncing from store to local state is always a pain (and an antipattern that React calls out in the documentation). Shouldn't this state be moved to the store already?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will move this to the redux store!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat no release notes Fix or feature not for release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants