I'm just starting to learn / work with river and I have a question about how to test. Here's my set up:
pgx as core driver
sqlc as access layer
migrate as my migration tool
currently using pgxmock as mock driver
On app start, I create the river client and pass it around to the modules which need to insert jobs. No concerns there, the app seems to work fine. However, I'm not sure how to (or if I can at all) get my tests to pass since I can't create a client from the mock pgx pool. I have been considering switching to dockertest for other reasons and that may solve the problem (but also may not) -- however, I'm hoping there's a way to reduce the initial scope.
Related question -- is it better to create the client and pass it as needed or create a client on the fly?
In my situation, I chose to do it on start up and pass it since the pool that's accessible deeper in the app is actually an interface since it can be a real pool or a mock pool. Since it's an interface, I likely can't create a client from the pool interface.
On the flip side, passing it forces you to pass it like riverClient *river.Client[pgx.Tx] -- so which ever mocking strategy you use has to yield the same instantiated type.
I tried peeking at how river itself is running its tests and I saw the internal/rivertest package. However, I'm not able to use that to create pools/clients. use of internal package github.com/riverqueue/river/internal/riverinternaltest not allowed
I'm just starting to learn / work with river and I have a question about how to test. Here's my set up:
On app start, I create the river client and pass it around to the modules which need to insert jobs. No concerns there, the app seems to work fine. However, I'm not sure how to (or if I can at all) get my tests to pass since I can't create a client from the mock pgx pool. I have been considering switching to dockertest for other reasons and that may solve the problem (but also may not) -- however, I'm hoping there's a way to reduce the initial scope.
Related question -- is it better to create the client and pass it as needed or create a client on the fly? In my situation, I chose to do it on start up and pass it since the pool that's accessible deeper in the app is actually an interface since it can be a real pool or a mock pool. Since it's an interface, I likely can't create a client from the pool interface.
On the flip side, passing it forces you to pass it like
riverClient *river.Client[pgx.Tx]-- so which ever mocking strategy you use has to yield the same instantiated type.I tried peeking at how river itself is running its tests and I saw the internal/rivertest package. However, I'm not able to use that to create pools/clients.
use of internal package github.com/riverqueue/river/internal/riverinternaltest not allowed