TDD构造函数Golang

时间:2018-11-16 00:31:07

标签: sql go tdd

即使有几篇文章,我也没有找到实质内容。因此,希望有一些人可以对此发表意见。

使我无法拥有真正的TDD工作流程的一件事是,我找不到一种干净的方法来测试必须连接到网络服务(如数据库)的事物。

例如:

type DB struct {
    conn *sql.DB
}

func NewDB(URL string) (*DB, err) {
    conn, err := sql.Open("postgres", URL)
    if err != nil {
        return nil, err
    }
}

我知道我可以将sql连接传递给NewDB,或直接传递给struct并将其分配给具有我需要的所有方法的接口,并且该接口很容易测试。但是在某个地方,我将不得不连接。我能够找到的对此进行测试的唯一方法是...

var sqlOpen = sql.Open
func CreateDB() *DB {
    conn, err := sqlOpen("postgres", "url...")
    if err != nil {
         log.Fatal(err)
    }

    dataBase = DB{
        conn: conn
    }
}

然后在测试中,将sqlOpen函数替换为返回具有相同签名的函数的东西,这将使一个测试用例出错,而对另一个测试用例不出错。但这感觉就像是黑客,特别是如果您要针对同一文件中的多个功能执行此操作。有没有更好的办法?我正在使用的代码库在程序包和网络连接中具有很多功能。因为我正在努力以干净的方式测试事物,所以这使我远离了TDD。

1 个答案:

答案 0 :(得分:1)

典型的业务应用程序在查询中具有很多逻辑。如果不进行测试,我们将大大减少测试的覆盖范围,并为回归错误留出空间。因此,模拟数据库存储库不是最佳选择。相反,我们可以模拟数据库本身并在SQL级别上测试如何使用它。

下面是使用DATA-DOG/go-sqlmock的示例代码,但是可能还有其他库可以模拟sql数据库。

首先,我们需要将sql连接注入到我们的代码中。 GO sql连接是一个令人误解的名称,它实际上是连接池,而不仅仅是单个DB连接。因此,即使您不编写测试,也要在合成根目录中创建单个*sql.DB并在代码中重用。

下面的示例显示了如何模拟Web服务。

一开始,我们需要创建带有注入连接的新处理程序:

// New creates new handler
func New(db *sql.DB) http.Handler {
    return &handler{
        db:     db,
    }
}

处理程序代码:

type handler struct {
    db     *sql.DB
}

func (h handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
  // some code that loads person name from database using id
}

对该模拟DB的代码进行单元测试。它使用stretchr/testify进行断言:

func TestHandler(t *testing.T) {
    db, sqlMock, _ := sqlmock.New()
    rows := sqlmock.NewRows([]string{"name"}).AddRow("John")
    // regex is used to match query
    // assert that we execute SQL statement with parameter and return data
    sqlMock.ExpectQuery(`select name from person where id \= \?`).WithArgs(42).WillReturnRows(rows)
    defer db.Close()

    sut := mypackage.New(db)

    r, err := http.NewRequest(http.MethodGet, "https://example.com", nil)
    require.NoError(t, err, fmt.Sprintf("Failed to create request: %v", err))
    w := httptest.NewRecorder()

    sut.ServeHTTP(w, r)
    // make sure that all DB expectations were met 
    err = sqlMock.ExpectationsWereMet()
    assert.NoError(t, err)
    // other assertions that check DB data should be here 
    assert.Equal(t, http.StatusOK, w.Code)
}

我们的测试针对数据库断言简单的SQL语句。但是使用go-sqlmock,可以测试所有CRUD操作和数据库事务。

上面的测试仍然有一个弱点。我们测试了我们的SQL语句是从代码执行的,但是我们没有测试它是否对我们的真实数据库有效。这个问题不能用单元测试解决。唯一的解决方案是针对真实数据库的集成测试。

我们现在处于更好的位置。业务逻辑已经在单元测试中进行了测试。我们不需要创建大量的集成测试来涵盖不同的场景和参数,而是每个查询仅需要一个测试即可验证SQL语法并与我们的数据库模式匹配。

测试愉快!