rivertest examples require internal package

[travisby]

Hello!

I was looking to setup tests for our project that's using river. I'm hoping to not need to spin up a postgres cluster to do so :).

I went to check out the rivertest package, which sounds like it serves this purpose.

I found the example https://pkg.go.dev/github.com/riverqueue/river/rivertest#example-package-RequireInserted -- unfortunately it contains this import:

"github.com/riverqueue/river/internal/riverinternaltest" so I'm unable to use it outside of river!

Is there an appetite for moving this to a non-internal package, or an alternative example that we can provide on using rivertest without the internal package?

Appreciate the thoughts!

[brandur]

@travisby Good and bad news.

We need some of these example test utilities outside of the main River repo for another demo app, so they're more likely than not to move to a non-internal package over the next week or so.

That's the good news. The bad news is that they'll be moving to rivershared, which makes no API stability guarantees. So while they'll be more accessible, depending on them might cause API breakages a few times a year.

Is there an appetite for moving this to a non-internal package, or an alternative example that we can provide on using rivertest without the internal package?

I'd suggest generally just stripping them out for your code as most are not needed outside of an example test situation.

e.g. Postgres connect:

// replace this
dbPool, err := pgxpool.NewWithConfig(ctx, riverinternaltest.DatabaseConfig("river_test_example"))

// with this
dbPool, err := pgxpool.New(ctx, "postgres:///my-db")

Just take this line out as it's only needed to ensure stability between tests:

if err := riverinternaltest.TruncateRiverTables(ctx, dbPool); err != nil {

And take this out too, as we only need to wait for jobs in example tests to ensure stable output:

waitForNJobs(subscribeChan, 1)

You're left with all non-internal API use that should be a working example.

In case you do need those functions for whatever reason, they're all quite simple implementations, so another easy path might be to just vendor them into your project.

[travisby]

Ah! I understand -- I thought riverinternaltes was including a fake/stub/mock driver, not connecting to a testing postgres.

In that case those methods are easy enough to grab out and reuse and it doesn't feel too smelly :).

When they do move to rivershared the api instability won't be too big of a deal, as these will be just tests! Will be happy to deal with that once they're moved.

Thanks for the explanation/suggestion!