-5

I have following code

func (s *MyRepo) InsertOrder(ctx context.Context, orderID string) error {
    query := `INSERT INTO orders (orderID) VALUES (?)`

    stmt, err := s.db.RawDatabase().PrepareContext(ctx, query)
    if err != nil {
        return err
    }
    defer stmt.Close()

    _, err = stmt.ExecContext(ctx, orderID)
    if err != nil {
        //log err
    }
    return err
}

And the corresponding test case is

func TestMyRepo_InsertOrder_Success(t *testing.T) {
    orderID := "orderID"
    mockDB, repo := getDBStore()
    query := `[INSERT INTO orders (orderID) VALUES (?)]`
    mockDB.ExpectPrepare(query).
        ExpectExec().
        WithArgs(orderID).
        WillReturnResult(sqlmock.NewResult(1, 1)).
        WillReturnError(nil)

    err := repo.InsertOrder(context.Background(), orderID)
    assert.Nil(t, err)
}

But this doesn't test if defer stmt.Close() has been called or not (which gets called once the function ends). How can I test this?

Em Ae
  • 8,167
  • 27
  • 95
  • 162
  • 4
    In what circumstances would `defer stmt.Close()` not be called? – Mikael Jun 14 '19 at 19:34
  • 3
    The only time a defer isn't going to be called is if the program exits, and you can't test anything in that case. – JimB Jun 14 '19 at 19:35
  • 2
    You're using a mock database, it should be able to detect if the statement was closed, right? – Adrian Jun 14 '19 at 19:42
  • 4
    Why would you test this? Such a test is only testing the go runtime, and if you don't trust that, I'd say there are bigger problems to deal with. – Jonathan Hall Jun 14 '19 at 21:19

1 Answers1

1

It looks like you are making use of data-dog's sqlmock package, so you ought to be able to use ExpectClose() to register the expectation that the database will be closed, and ExpectationsWereMet() to collect this information.

If you're using some other package, feel free to link it; there's probably something similar available, and worst-case you can write your own wrapper around their wrapper. Making sure that a particular method of a particular dependency was called is a fairly common desire when developers write tests using mocks, so most of the better mock packages will go out of their way to provide some sort of API to check that.

As noted in the comments on this question, tests of this nature are often of somewhat questionable value and can seem like they exist more to increase a dubious metric like % code coverage than to increase code reliability or maintainability.

Jesse Amano
  • 800
  • 5
  • 16