> Iām going to add a recommendation in our docs for pgtestdb, particularly for users aiming to test end-to-end (i.e. job inserted by client ā fully completed by worker).
Just want to say thank you to Brandur for doing such a cool experiment. Last year I actually explored the River test suite to understand how they made it work so quickly ā he's understating it when he says their implementation is "gold standard."
I'm both surprised and excited to hear that pgtestdb, out of the box, can give anyone a ~nearly as fast experience.
Going to have to throw some tokens at pooling... very interesting idea.
> Iām going to add a recommendation in our docs for pgtestdb, particularly for users aiming to test end-to-end (i.e. job inserted by client ā fully completed by worker).
That's exactly what I did to learn River ā implementing simple apps and testing their execution with pgtestdb: https://github.com/lukasschwab/river-playground
The starter skeleton was LLM-generated and not quite perfect, but discovering the coding agent's mistakes was satisfying in its own right.
Just want to say thank you to Brandur for doing such a cool experiment. Last year I actually explored the River test suite to understand how they made it work so quickly ā he's understating it when he says their implementation is "gold standard."
I'm both surprised and excited to hear that pgtestdb, out of the box, can give anyone a ~nearly as fast experience.
Going to have to throw some tokens at pooling... very interesting idea.
Thank you, Brandur!