Is there a method that doesn't alter the original connection pool ?

[kizuna-lek]

Is your feature request related to a problem? Please describe.
In the example on the homepage, it seems that i should wrap the original connection pool into a new interface to facilitate passing it to pgxmock.

type PgxIface interface {
	Begin(context.Context) (pgx.Tx, error)
	Close(context.Context) error
}

For example, i have this struct:

type Manager struct {
    Pool    *pgxpool.Pool
    // other variables
}

and some function like this:

func (mgr *Manager) Query(ctx context.Context, sql string) (result []byte, err error) {
    rows, err := mgr.Pool.Query(ctx, sql)
    // lots of steps
}

Do I must modify my structure in this way？

type Manager struct {
    Pool    *PgxIface
    // other variables
}

Ideally, I would prefer not to modify this Manager struct.
Describe the solution you'd like
I have tried this way:

mock, err := pgxmock.NewPool()
manager.Pool = mock.(*pgxpool.Pool)

but had error : Impossible type assertion: '*pgxpool.Pool' does not implement 'PgxPoolIface'
Additional context
Does this modification approach seem reasonable?
Is it necessary and feasible to implement such a modification?
I am still learning to write unit tests.If I make some basic mistakes, I would appreciate your guidance.

[pashagolub]

Hello, and thanks for your interest.

Do I must modify my structure in this way？

Well, you don't need to use pgxmock.PgxIface. It's possible, but I would recommend something other than that for one reason: you don't want to use anything from the testing environment in your production build. To overcome this problem, you may define and use your own interface. As a start, you may copy-paste PgxPoolIface and PgxIface into your code. You can even rename it. The main thing is that this interface will define the methods of the pool.

Check my own implementation of this technique in pg_timetable.

Is it necessary and feasible to implement such a modification?

We can mock only interfaces. Because interface is an agreement, not an implementation. For example, it's straightforward with sql.Db because it's an interface. It's a contract on what methods underlying objects should implement.

On the contrary, pgx provides us with the structs pgxConn and pgxPool. That means they are hard coded. If you use objects (structs) in your struct, that means you nail down their functionality. That's precisely why we want to put our own interfaces in the struct. This way, we can use unique mocking test objects during tests and real pgx objects during the actual workload.

I hope I'm clean enough. If not, you may try to read this article. Check the "Interface substitution" part.

I am still learning to write unit tests. If I make some basic mistakes, I would appreciate your guidance.

I can completely understand your question and frustration. I've been there. :) As I wrote, it's easier to mock sql.Db because it was made to be an ephemeral interface. That's the reason why pgx library exists in the first place. Because it's nearly impossible to write native PostgreSQL implementation of some functions following sql.Db interface contract.

[kizuna-lek]

Thanks for your reply.
pg_timetable is really a good example.
I believe I understand what you mean, This has been truly helpful to me.

Because interface is an agreement, not an implementation

Especially this sentence deepened my understanding of "interface".
I will define and use my own interface and write UT with pgxmock.
Thank you once again for helping me resolve this problem.