erikstmartin / go-testdb Goto Github PK

Implement logic to stub prepared statements

Implement logic to stub transactions

We would like to test that a query gets invoked with the expected arguments. This is currently only possible for SetExecFunc() not for StubQuery() or SetQueryFunc().

We have a func that uses sth like db.DbClient.Model(&Countable{}).Where("filter = ?", filter).Count(&count), any way to set query that could help to test with testdb?

Should probably remove whitespace and calculate a sha/hash of the sql call instead of using the actual sql.

These blocks check for q.result and q.rows being nil, but these are valid cases where errors have been stubbed. The anonymous functions return errors.

https://github.com/erikstmartin/go-testdb/blob/master/conn.go#L39-L49
https://github.com/erikstmartin/go-testdb/blob/master/conn.go#L51-L58

Write tests and investigate to see if error stubbing for prepared statements as broken, and fix if this is the case.

Prepared statement support seems to have been added, if so this should be removed from the todo list.

need to implement the Exec method

This logic makes times specific to this driver, by removing it we support the Go-MySQL-Driver

At present either a string or time.Time is returned for the driver.Value within RowsFromCSVString. It would be nice to add support returning a sql.NullString.

It could look something like:

type testDriver struct {
    // as is
    enableNullParsing bool
}

// Within RowsFromCSVString...
if d.enableTimeParsing {
    // as is
} else if d.enableNullParsing && v == "" {
    row[i] = sql.NullString{}
} else {
    row[i] = v
}

Happy to knock this up into a PR if it's something you'd like to see added.

I found it quite hard to trigger the unexpected error condition below. How did you guys managed to please go test -cover in your SQL code?

        // Initialize SQL query
        rows, err := q.Query(SomeSQLQuery)
        if err != nil {
                panic("failed to initialize SQL query")
        }
        defer rows.Close()

        // Execute SQL query
        var a, b, c sql.NullString
        for rows.Next() {
                err = rows.Scan(&a, &b, &c)
                if err != nil {
                        panic("failed to get SQL results")
                }
                // ...
        }

        if rows.Err() != nil {
                panic("unexpected SQL error")
        }

Would you mind providing a license for this? BSD would be a good choice. Otherwise, we have to assume you reserve all rights, and nobody can use it. If that's what you want, it's probably worth explicitly stating that anyway.

Does go-testdb support calling the same query more than once?

Something like this :

func TestStubQueryRowTwice(t *testing.T) {
    defer Reset()

    db, _ := sql.Open("testdb", "")

    values := []int{5, 6}

    query := "select bar from foo"
    columns := []string{"bar"}
    var result string

    for _, value := range values {
        result += strconv.Itoa(value) + "\n"
    }

    StubQuery(query, RowsFromCSVString(columns, result))
    StubQuery(query, RowsFromCSVString(columns, result))

    for i := 0; i < 2; i++ {
        rows, errQuery := db.Query(query)

        if rows == nil {
            t.Fatal("stub query should have returned rows")
        }

        if errQuery == sql.ErrNoRows {
            t.Fatal("stub query should have returned rows")
        }

        var j int
        for rows.Next() {
            var count int
            err := rows.Scan(&count)

            if err != nil {
                t.Fatal(err)
            }

            if count != values[j] {
                t.Fatal("failed to return count")
            }

            j += 1
        }

        if j != 2 {
            t.Fatal("2 rows expected")
        }
    }
}

This library is very handy, but when used in tests of concurrent code will trigger the go race detector.

A very simple case is if you have two tests that both call something like testdb.SetQueryFunc. The first test to run uses the query function in a goroutine, the call to set the query function in the second test can be detected as a race.

The race detector is logically correct; a value was read from and written to by different goroutines with no synchronization. However, this should be safe usage of the testdb library, as the two tests are never run concurrently.