Thanks to visit codestin.com
Credit goes to github.com

Skip to content

chore: use idiomatic test setup in notification tests #14416

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

Merged
merged 2 commits into from
Aug 23, 2024

Conversation

dannykopping
Copy link
Contributor

Looking back at the tests I implemented a while back for notifications, I realized the way I was setting up the database was wrong - or at least incomplete. I'm more familiar with our testing idioms now and this was bugging me.

setup and setupInMemory are both covered by coderdtest.New, depending on what the DB_FROM and DB environment variables are.

This doesn't really change anything for tests which used setup (since those were previously and will still provision a postgres instance to test against), but for the setupInMemory cases it now actually tests them against a real database when we run make test-postgres; previously they were only running in-memory.

This PR also includes a couple other minor drive-by fixes, which I've called out below.

Comment on lines 253 to 254
rbac.ResourceDeploymentConfig.Type: {policy.ActionCreate, policy.ActionUpdate, policy.ActionDelete},
rbac.ResourceNotificationTemplate.Type: {policy.ActionCreate, policy.ActionUpdate, policy.ActionDelete},
Copy link
Contributor Author

Choose a reason for hiding this comment

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

These two permissions were necessary, and since tests using setupInMemory never hit dbauthz we never encountered this mismatch of permissions.

@@ -723,19 +732,6 @@ func TestNotificationTemplatesCanRender(t *testing.T) {
},
},
},
{
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This test did not belong here.

@dannykopping dannykopping marked this pull request as ready for review August 23, 2024 13:00
@dannykopping dannykopping force-pushed the dk/notifications-tests branch 2 times, most recently from 17949db to 6a28ab0 Compare August 23, 2024 13:37
@dannykopping dannykopping force-pushed the dk/notifications-tests branch from 6a28ab0 to 148fac8 Compare August 23, 2024 13:46

// WHEN: notifications are enqueued which should succeed and fail
_, err = enq.Enqueue(ctx, user.ID, notifications.TemplateWorkspaceDeleted, map[string]string{"nice": "true"}, "") // Will succeed.
_, err = enq.Enqueue(ctx, user.ID, notifications.TemplateWorkspaceDeleted, map[string]string{"nice": "true", "i": "0"}, "") // Will succeed.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Typical problem here: not all the business logic was in dbmem, so the pg server rejects duplicate notifications and we needed to avoid that.

Copy link
Member

@johnstcn johnstcn left a comment

Choose a reason for hiding this comment

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

👍

@dannykopping dannykopping merged commit a4d785d into main Aug 23, 2024
27 checks passed
@dannykopping dannykopping deleted the dk/notifications-tests branch August 23, 2024 14:29
@github-actions github-actions bot locked and limited conversation to collaborators Aug 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants