You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, coderdtest uses a fake notifications enqueuer implementation that simply stores an internal list of enqueued notification messages.
The 'real' implementation actually stores enqueued notification messages in the database.
End result: integration tests end up not checking dbauthz RBAC.
This is partially addressed in #15478 but the actual implemention is not 100% in line with reality.
Proposed solution
Our tests in coderd should use the 'real' notifications.StoreEnqueuer, and enqueued notifications should be stored in the configured database.Store used by the tests.
However, there are some ergonomics considerations to be considered here, as tests will generally want to:
Perform some action
Wait for a notification to be enqueued asynchronously
Perform assertions on the notification
Right now, we would need to resort to polling in order to accomplish this.
An option is to place a thin wrapper around notifications.StoreEnqueuer that exposes the following methods to tests:
Wait for a notification to be enqueued successfully
I took a stab at this in #17449 but this approach means we will need to impelement dbmem.EnqueueNotificationMessageNoLock() to avoid re-entrant locks. I think a better approach would be to phase out the usage of FakeEnqueuer() entirely in favour of a mock where applicable, and default to the real deal.
Problem
Right now,
coderdtest
uses a fake notifications enqueuer implementation that simply stores an internal list of enqueued notification messages.The 'real' implementation actually stores enqueued notification messages in the database.
End result: integration tests end up not checking
dbauthz
RBAC.This is partially addressed in #15478 but the actual implemention is not 100% in line with reality.
Proposed solution
Our tests in
coderd
should use the 'real'notifications.StoreEnqueuer
, and enqueued notifications should be stored in the configureddatabase.Store
used by the tests.However, there are some ergonomics considerations to be considered here, as tests will generally want to:
Right now, we would need to resort to polling in order to accomplish this.
An option is to place a thin wrapper around
notifications.StoreEnqueuer
that exposes the following methods to tests:cc @dannykopping
The text was updated successfully, but these errors were encountered: