在我发现我的程序存在漏洞之后，我就解决了这个问题。但是，现在我正试图找出如何在 Go 测试中“测试 ”泄漏连接？这是我的问题。

我曾尝试更改测试中的请求数量，但没关系。无论我做什么，我测试中的当前 TCP 连接数都保持不变。

func TestLeakingConnections(t *testing.T) {
    getter := myhttp.New()

    s := newServer(ok)
    defer s.Close()

    cur := tcps(t)
    for i := 0; i < 1000; i++ {
        r, _ := getter.GetWithTimeout(s.URL, time.Millisecond*10)
        r.Body.Close()
    }

    for tries := 10; tries >= 0; tries-- {
        growth := tcps(t) - cur
        if growth > 5 {
            t.Error("leaked")
            return
        }
    }
}

// find tcp connections
func tcps(t *testing.T) (conns int) {
    lsof, err := exec.Command("lsof", "-n", "-p", strconv.Itoa(os.Getpid())).Output()
    if err != nil {
        t.Skip("skipping test; error finding or running lsof")
    }

    for _, ls := range strings.Split(string(lsof), "\n") {
        if strings.Contains(ls, "TCP") {
            conns++
        }
    }
    return
}

func newServer(f http.HandlerFunc) *httptest.Server {
    return httptest.NewServer(http.HandlerFunc(f))
}

func ok(w http.ResponseWriter, r *http.Request) {
    w.Header().Add("Content-Type", "application/xml")
    io.WriteString(w, "<xml></xml>")
}

// myhttp package

// ...other code omitted for clarification

func (g *Getter) GetWithTimeout(
    url string,
    timeout time.Duration,
) (
    *http.Response, error,
) {
    // this is the leaking part
    // moving this out of here will stop leaks
    transport := http.Transport{
        DialContext: (&net.Dialer{
            Timeout: timeout,
        }).DialContext,
        TLSHandshakeTimeout:   timeout,
        ResponseHeaderTimeout: timeout,
        ExpectContinueTimeout: timeout,
    }

    client := http.Client{
        Timeout:   timeout,
        Transport: &transport,
    }

    return client.Get(url)
}

// fixture worker package

// some outside code injects getter into fixture_worker like this:
getter := myhttp.New()

// NewWithTimeout creates a new fetcher with timeout threshold
func NewWithTimeout(
    getter myhttp.HTTPGetter,
    fetchURL string,
    timeout time.Duration,
) *Fetcher {
    return &Fetcher{getter, fetchURL, timeout}
}

// Fetch fetches fixture xml
func (f *Fetcher) Fetch() (*parser.FixtureXML, error) {
    res, err := f.getter.GetWithTimeout(f.fetchURL, f.timeout)
    if err != nil {
        if res != nil && res.Body != nil {
            res.Body.Close()
        }
        return nil, errors.Wrap(err, ErrFetch.Error())
    }
    defer res.Body.Close()

    ioutil.ReadAll(res.Body)

    return &parser.FixtureXML{}, nil
}

fixture worker lsof 的输出:https://pastebin.com/fDUkpYsE

测试输出:https://pastebin.com/uGpK0czn

测试永远不会泄漏，而 fixture worker 会泄漏。

Fixture worker 使用与测试相同的代码，使用 myhttp 包请求 http 获取。

最佳答案

如果您希望您的测试代表现实，您需要以与测试之外相同的方式使用它。在这种情况下，您没有阅读任何响应，并且传输恰好在防止丢失连接，因为它会尽快丢弃它们，因为它们无法重复使用。

读取响应将使用连接，并使其进入“泄漏”状态。您还需要在所有情况下正确处理错误，并且始终需要 Close() 响应主体。处理 http 响应并确保其关闭的模式非常简单，并且不一定需要测试(请参阅 What could happen if I don't close response.Body in golang?)

    resp, err := GetWithTimeout(s.URL)
    if err != nil {
        t.Fatal(err)
    }
    ioutil.ReadAll(resp.Body)
    resp.Body.Close()

这可以说是有限的用处，因为最常见的错误将由不正确的错误和响应处理引起，而您没有测试它，因为测试首先需要正确地进行。

这里剩下的问题是您的 GetWithTimeout 方法返回一个错误值和一个有效的 http 响应，这与 http 包文档以及大多数用户的期望相矛盾。如果您要插入错误，最好在同一点处理响应以确保正文被关闭和丢弃。

最后，GetWithTimeout 的大部分内容都是多余的，因为不仅每次都创建 Transports 不正确，而且每个请求都创建一个 http.Client 通常是不必要的，因为它们应该被重用并且对同时使用。

关于testing - 如何在 Go 测试中测试泄漏连接？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45746753/