I have to use the PgxConnIface interface in my source code?

[Nikola-Milovic]

Hello everyone, can someone please clarify this, I am a bit confused.

The docs state does not require any modifications to your source code, but I am supposed to use PgxConnIface in my repository instead of the *pgx.Conn? This is clearly modifying my source code and is definitely unnatural to use an interface from a mocking library in my source code, the mocking library should adapt to the thing it's trying to mock, right? Is there any reason the mock connection cannot adhere to the pgx.Conn? The expected behaviour would be that I can just pluck in the Mock instead of the real database and have it return results I give it or whatever. I am probably doing something really incorrectly.

I expected that I can do something like this

type AccountService struct {
	db *pgx.Conn
}

func TestAccountCreation(t *testing.T) {
	mock, err := pgxmock.NewConn()
	if err != nil {
		t.Fatalf("an error '%s' was not expected when opening a stub database connection", err)
	}
	defer mock.Close(context.Background())

	sut := AccountService{
		db: mock, //Expecting this to just work
	}

But I get the following error

cannot use mock (variable of type pgxmock.PgxConnIface) as *pgx.Conn value in struct literal

Coming from some other languages to Go, this has been super confusing, there doesn't seem to be a clear-cut solution to testing using Postgres as your database. Also is there support for *pgxpool.Pool as that is clearly recommended to be used in the documentation?

[pashagolub]

Hello @Nikola-Milovic!

Thanks a lot for your question. Let me answer by quoting the article "Mocking Techniques for Go":

In Go, interfaces are implicitly and statically satisfied by implementing types. That means you do not need to explicitly mention that your type will “implement” an interface. If it can do the behaviors of the interface, it is allowed to be treated that way. The static satisfaction means you find out at compile time whether or not your concrete type can be substituted as an interface type. This is one distinguishing mark from true “duck typing” that you see in dynamic languages like python. Because of this, interfaces are incredibly powerful for mocking in tests. The following technique follows the “D” from SOLID design pattern considerations — API boundaries should depend on abstractions rather than concrete implementations.

Sometimes we need to mock a method defined on a type. The simplest way to do this is to define an interface that describes the behaviors that you need rather than dealing with the concrete type. One example is reading from a file. Maybe we do not want to actually read from a file in our unit test...

TL;DR: We cannot mock struct because it has defined implementation already. What we can mock is the interface because we only know the methods it should provide but implementation is hidden and depends on the object (real one or mocked).

Now, I see you are struggling to understand how to use such kind of interface in your code. You don't need to use any interfaces defined by pgxmock, e.g. pgxMockIface. Instead, your code definition should look like this.

1. If it's enough in your case you may use pgx.Tx transaction interface:

type AccountService struct {
	db pgx.Tx
}

2. If you really need a connection or a pool instead, then you need to define your own interface because there is no available in pgx:

type PgxConnIface interface {
	pgx.Tx
	Begin(context.Context) (pgx.Tx, error)
	Close(ctx context.Context) error
	Ping(context.Context) error
        //add more methods if you need
}

type AccountService struct {
	db PgxConnIface
}

func main() {
  accsrv := AccountService{}
  accsrv.db, err := pgx.Connect(context.Background(), "postgres://rolname@hostname/dbname")
...
}

Please pay attention to how examples are implemented.

If you are comparing how the mocking library for db/sql is implemented, then you may notice that sql.Conn uses interfaces underneath. That is how one can easily mock real database drivers. But since pgx is working solely with PostgreSQL there is no need in this abstraction layer and that's why one needs to use own one for testing purposes.

[Nikola-Milovic]

Thank you for the informative answer!

[Nikola-Milovic]

Just a quick question, would it be fair to say that this is a poor design choice from pgx? Wouldn't having the struct implement somekind of interface be doable and allow for this kind of use-cases (without a doubt important use-cases)?