-
Notifications
You must be signed in to change notification settings - Fork 92
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
Drop client Schema
configuration
#18
Conversation
@@ -141,7 +142,7 @@ func newTestClient(ctx context.Context, t *testing.T, config *Config) *Client[pg | |||
return client | |||
} | |||
|
|||
func runClient(ctx context.Context, t *testing.T, client *Client[pgx.Tx]) { | |||
func startClient(ctx context.Context, t *testing.T, client *Client[pgx.Tx]) { |
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.
Sorry for the spam, but renamed this since we renamed Run
-> Start
.
@@ -1896,7 +1967,7 @@ func Test_Client_UnknownJobKindErrorsTheJob(t *testing.T) { | |||
require.NoError(client.Stop(ctx)) | |||
} | |||
|
|||
func Test_Client_Run_Error(t *testing.T) { | |||
func Test_Client_Start_Error(t *testing.T) { |
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.
Same idea here. Run
-> Start
.
return client | ||
} | ||
|
||
func Test_Client(t *testing.T) { |
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.
Started a new branch of client tests because it's not clear what should go where in here anymore, and I'm trying to put in something where new tests can be added without starting a fresh test every time. We'll try to take advantage of JobArgsReflectKind
and WorkFunc
in subtests so that args and work definition can be colocated right inside the test rather than being floating around in global state somewhere.
StartInsertAndWork
below is a basic client test (not related to the Schema
change) added to show roughly what this look like.
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.
Nicely done, I like the new test pattern. If nothing else, inline worker definitions are great for concise & easy to follow tests.
As discussed in #15, the `Schema` configuration parameter doesn't actually do anything, and we realized that it's possible to support this feature by using an alternate configuration for pgxpool in `search_path`. Here, drop `Schema` and add a test that verifies that this technique works. So as to not have to create and migrate an alternate schema, we cheat a little bit by repointing the schema and then just verifying that we can't find a `river_job` table there. I'm finding the test hierarchy in `client_test.go` to be pretty confusing in determining on what best practice is for what should go where, so I'm starting out with a new `Test_Client` which I'm hoping we can start using as a base for most of the general tests in here in a more reusable way. I leverage `JobArgsReflectKind` and `WorkFunc` in its subtests so that it's not dependent on our various global job args that are defined all over the place. Instead, args and the work routine are colocated right inside the test. Configuring an alternate schema is definitely going to need its own documentation page somewhere because it's not obvious, but that'll come separately. Fixes #15.
e0ffce5
to
32b8d3e
Compare
TY TY. |
As discussed in #15, the
Schema
configuration parameter doesn'tactually do anything, and we realized that it's possible to support this
feature by using an alternate configuration for pgxpool in
search_path
.Here, drop
Schema
and add a test that verifies that this techniqueworks. So as to not have to create and migrate an alternate schema, we
cheat a little bit by repointing the schema and then just verifying that
we can't find a
river_job
table there.I'm finding the test hierarchy in
client_test.go
to be prettyconfusing in determining on what best practice is for what should go
where, so I'm starting out with a new
Test_Client
which I'm hoping wecan start using as a base for most of the general tests in here in a
more reusable way. I leverage
JobArgsReflectKind
andWorkFunc
in itssubtests so that it's not dependent on our various global job args that
are defined all over the place. Instead, args and the work routine are
colocated right inside the test.
Configuring an alternate schema is definitely going to need its own
documentation page somewhere because it's not obvious, but that'll come
separately.
Fixes #15.