在 Golang 中测试包装函数的惯用方法是什么？

Question

It is not unusual, when we have a function with a lot of parameters, to create some companion-functions that use the general function with pre-defined parameters. This is the usual alternative to defining default value for parameters, something Go doesn't allow.

A very simple example would be to create a SquareArea function that uses a more general RectangleArea function.

func SquareArea(side int) int {
    return RectangleArea(side, side)
}

func RectangleArea(width int, length int) int {
    if width < 0 || length < 0 {
        return 0
    }
    return width * length
}

For theses functions one can create the (kinda) table tests

func TestSquareArea(t *testing.T) {
    tests := []struct {
        side     int
        expected int
    }{
        {side: -1, expected: 0},
        {side: 0, expected: 0},
        {side: 1, expected: 1},
        {side: 2, expected: 4},
        {side: 100, expected: 10000},
    }
    for idx, test := range tests {
        if result := SquareArea(test.side); test.expected != result {
            t.Errorf("test #%d expected != result (%d!=%d)", idx, test.expected, result)
        }
    }
}

func TestRectangleArea(t *testing.T) {
    tests := []struct {
        width    int
        length   int
        expected int
    }{
        {width: -1, length: -1, expected: 0},
        {width: -1, length: 1, expected: 0},
        {width: 1, length: -1, expected: 0},
        {width: 2, length: 1, expected: 2},
        {width: 1, length: 2, expected: 2},
        {width: 3, length: 2, expected: 6},
        {width: 2, length: 3, expected: 6},
        {width: 10, length: 100, expected: 1000},
        {width: 100, length: 10, expected: 1000},
    }
    for idx, test := range tests {
        if result := RectangleArea(test.width, test.length); test.expected != result {
            t.Errorf("test #%d expected != result (%d!=%d)", idx, test.expected, result)
        }
    }
}

Is this the right way?

For more complex functions, and more companion-functions , it seems that this approach would create a lot of tests while essentially testing several times the same underlying code (ie RectangleArea ).

I feel that testing SquareArea should only ensure that RectangleArea is called with the correct parameters.

Is this code approach (having there both functions RectangleArea and SquareArea ) idiomatic in Golang? Is there another way to do it on Golang?

With a language like Python, I would mock the RectangleArea function.

To mimic this, I would do something like:

var rectangleAreaFunction = RectangleArea

func SquareArea(side int) int {
    return rectangleAreaFunction(side, side)
}

func RectangleArea(width int, length int) int {
    if width < 0 || length < 0 {
        return 0
    }
    return width * length
}

with the tests:

func TestSquareArea(t *testing.T) {
    call:= ""
    mock:= func(width int, length int) int {
        call = fmt.Sprintf("func(%d,%d)", width, length)
        return 0
    }
    rectangleAreaFunction = mock
    tests := []struct {
        side     int
        expected string
    }{
        {side: -1, expected: "func(-1,-1)"},
        {side: 0, expected: "func(0,0)"},
        {side: 1, expected: "func(1,1)"},
        {side: 2, expected: "func(2,2)"},
        {side: 100, expected: "func(100,100)"},
    }
    for idx, test := range tests {
        call = ""
        SquareArea(test.side)
        if test.expected != call {
            t.Errorf("test #%d expected != call (%s!=%s)", idx, test.expected, call)
        }
    }
}


func TestRectangleArea(t *testing.T) {
    tests := []struct {
        width    int
        length   int
        expected int
    }{
        {width: -1, length: -1, expected: 0},
        {width: -1, length: 1, expected: 0},
        {width: 1, length: -1, expected: 0},
        {width: 2, length: 1, expected: 2},
        {width: 1, length: 2, expected: 2},
        {width: 3, length: 2, expected: 6},
        {width: 2, length: 3, expected: 6},
        {width: 10, length: 100, expected: 1000},
        {width: 100, length: 10, expected: 1000},
    }
    for idx, test := range tests {
        if result := RectangleArea(test.width, test.length); test.expected != result {
            t.Errorf("test #%d expected != result (%d!=%d)", idx, test.expected, result)
        }
    }
}

But it seems that using a variable to hold the actual function in order to do the tests is bad.

Another example of this kind of situation would be when treating the http request method through a first triage function:

func Triage(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/html; charset=utf-8")
    // some other common code like adding some context
    *r = *(r.WithContext(context.WithValue(r.Context(), "key", "value")))
    switch r.Method {
    case POST:
        triagePost(w, r)
    default:
        triageGet(w, r)
    }
}

func triagePost(w http.ResponseWriter, r *http.Request) {
    // some code
}

func triageGet(w http.ResponseWriter, r *http.Request) {
    // some code
}

Full fledged tests for the 3 functions would have a lot of useless repetitions Limiting the test of the Triage function to:

• check that the common code is correctly executed
• check that the correct function ( triagePost or triageGet ) is correctly called based on the r.Method

would prevent such repetitions while testing the actual behavior.

Or having this type of code (triage function) is totally incorrect in Golang?

Answer 1

Go refrains from mocking as much as possible. Let's try to follow the idiomatic approach (test the real code) and see how far it brings us.

Function SquareArea calls RectangleArea with the same value for the two parameters. Testing SquareArea is not concerned about the correctness of RectangleArea.

A single test case for SquareArea will give 100% test coverage of it, there is not even the need for a table driven test.

If there is concern to test the correctness of RectangleArea when given the two parameters with the same value, then this test case should be added directly to the table-driven test for RectangleArea.

For sure, if SquareArea were more complicated, then we would need a table driven test. But also in this case, we would have to focus on what SquareArea does, not on what RectangleArea does.

Said in another way, when deciding how to test a function (or anything actually), I have found that the following approach helps reducing doubts:

1. Keep repeating myself: what am I actually testing???
2. Use code coverage to guide me. Code coverage (and fixating on a percentage) can be a double-edged sword, but used wisely as guidance can be very useful.
3. Challenge the existence of a test. The problem with tests is that their mere existence tends to justify the existence of the tested code. If the tested code is not used anywhere else, delete it and its tests. This is, in my experience, the most valuable lesson of TDD (when applicable).