【问题标题】：Proper testing of http routes in go在 go 中正确测试 http 路由
【发布时间】：2017-12-30 11:24:40
【问题描述】：

我有 5 个端点，它们有 GET、POST 和 DELETE 等方法进行测试。我使用内置测试包中的 go 编写测试用例。我担心我遗漏了一些我并不印象深刻的案例。我已经在代码审查中发布了我的测试用例进行审查，但我没有得到任何回应。我也关注了这个帖子Testing HTTP routes in golang。所有这些测试用例都在检查响应代码。

问题在于，我的大多数测试用例都遵循类似的模式，我以不同的格式发布数据并检查响应代码。我强烈觉得当我将它推送到 prod 时，我错过了一些会破坏我的 API 的东西。我需要一些关于测试这些路由的见解，以便我有信心将 api 推送到 prod。

main_test.go

func TestSigHandler(t *testing.T){

    test_cases := []string{"2021205"}  
    // GET Testing
    for _, method := range test_cases{
        usersUrl = fmt.Sprintf("%s/1/sig/id/%s", server.URL, method) //Grab the address for the API endpoint
        request, err := http.NewRequest("GET", usersUrl, nil)
        res, err := http.DefaultClient.Do(request)

        if err != nil {
            t.Error(err) //Something is wrong while sending request
        }

        if res.StatusCode != 200  {
            t.Errorf("Something went wrong : ", res.StatusCode) //Uh-oh this means our test failed
        }
    }

    // POST Testing
        sig := []byte( `{
        "raw": "a new sig"
    }`)
        usersUrl = fmt.Sprintf("%s/1/sig/id/2021205", server.URL) //Grab the address for the API endpoint
        request, err := http.NewRequest("POST", usersUrl, bytes.NewBuffer(sig))
        if err != nil{
            t.Error(err)
        }
        request.Header.Set("Content-Type", "application/json")
        res, err := http.DefaultClient.Do(request)

        if err != nil {
            t.Error(err) //Something is wrong while sending request
        }

        if res.StatusCode != 200  {
            t.Errorf(" Something Went Wrong: ", res.StatusCode) //Uh-oh this means our test failed
        }

        // DELETE Testing

        sigs_delete_cases := []string{ "1000345"}
        for _, sig_to_be_deleted := range sigs_delete_cases{
            usersUrl = fmt.Sprintf("%s/1/sig/id/%s", server.URL, sig_to_be_deleted) //Grab the address for the API endpoint
            request, err := http.NewRequest("DELETE", usersUrl, nil)
            res, err := http.DefaultClient.Do(request)

            if err != nil {
                t.Error(err) //Something is wrong while sending request
            }

            if res.StatusCode != 200  {
                t.Errorf("Tried to delete a reserved Id : ", res.StatusCode) //Uh-oh this means our test failed
            }
        }


}

【问题讨论】：

我认为这对 SO 来说太宽泛了。如果您只检查状态代码，那么您担心是对的，您应该检查响应正文和副作用（例如，如果您发布一个新的小部件，它是否正确地保存到数据库中，或者您的情况可能是）。
@Adrian 我正在尝试以实际格式和错误格式发布数据。如果它没有被发布，我期待一个不是 200 的响应代码并调用错误方法。我用我的测试用例编辑了这个问题。
没有人可以为你回答这个问题。您可能收到的请求空间是无限的。您可以随时尝试Fuzz testing 之类的方法，但最终由您决定什么是“足够”的测试。
@Adrian 如果我进行模糊测试，我的 api 肯定会崩溃。到目前为止，我正在使用剩余的端点执行此操作：“（例如，如果您发布一个新的小部件，它是否会正确地保存到数据库中，或者无论您的情况如何）。”
哇...定义“休息”？无效的请求不应该“破坏”任何东西，它们应该返回“你给了我无效的输入”类型的错误。如果 fuzzing 会破坏你的 API，那么它就不稳定。

标签： unit-testing go

【解决方案1】：

我喜欢这样做：

建立持续集成。如果您的项目是开源的，您可以使用Travis CI 之类的服务 - 它非常易于安装。这有助于您了解更改如何影响代码。
设置代码测试覆盖率。它允许您查看哪些源代码行被测试覆盖，哪些未被覆盖，以及极有可能出现的错误。当然，代码覆盖工具并不是万能的。如果检查了线路，并不意味着它绝对没问题，并且不会因其他输入而失败。但它有助于维护良好的代码和查找错误。对于开源，您可以使用 coveralls.io。有一个特殊的goveralls 插件。
为了解决上述问题，您可以使用所谓的模糊测试 - 随机输入的探索性测试来找出根本原因。有标准的https://golang.org/pkg/testing/quick/ 和非标准的包https://github.com/dvyukov/go-fuzz。

然后我进行测试，它们既有正面的也有负面的。我尝试检查有错误、超时、不正确回复的情况。

对于我的测试，我像往常一样使用客户端 http 所以 httptest 包。

【讨论】：