How Can We Efficiently Table Test Go Generic Functions with Different Type Arguments?

Testing Table Go Generic Functions

In Go 1.18, programmers can take advantage of its new generics feature. While exploring this new capability, developers may encounter challenges in performing table testing. One such challenge is explored in this discussion, particularly in the context of testing generic functions with table data.

The issue arises when attempting to instantiate generic functions with different types of arguments during table testing. To address this, developers often resort to redeclaring the testing logic for each function, as exemplified by the following code snippet:

package main

import (
    "testing"

    "github.com/stretchr/testify/assert"
)

type Item interface {
    int | string
}

type store[T Item] map[int64]T

// add adds an Item to the map if the id of the Item isn't present already
func (s store[T]) add(key int64, val T) {
    _, exists := s[key]
    if exists {
        return
    }
    s[key] = val
}

func TestStore(t *testing.T) {
    t.Run("ints", testInt)
    t.Run("strings", testString)
}

type testCase[T Item] struct {
    name     string
    start    store[T]
    key      int64
    val      T
    expected store[T]
}

func testString(t *testing.T) {
    t.Parallel()
    tests := []testCase[string]{
        {
            name:  "empty map",
            start: store[string]{},
            key:   123,
            val:   "test",
            expected: store[string]{
                123: "test",
            },
        },
        {
            name: "existing key",
            start: store[string]{
                123: "test",
            },
            key: 123,
            val: "newVal",
            expected: store[string]{
                123: "test",
            },
        },
    }
    for _, tc := range tests {
        t.Run(tc.name, runTestCase(tc))
    }
}

func testInt(t *testing.T) {
    t.Parallel()
    tests := []testCase[int]{
        {
            name:  "empty map",
            start: store[int]{},
            key:   123,
            val:   456,
            expected: store[int]{
                123: 456,
            },
        },
        {
            name: "existing key",
            start: store[int]{
                123: 456,
            },
            key: 123,
            val: 999,
            expected: store[int]{
                123: 456,
            },
        },
    }
    for _, tc := range tests {
        t.Run(tc.name, runTestCase(tc))
    }
}

func runTestCase[T Item](tc testCase[T]) func(t *testing.T) {
    return func(t *testing.T) {
        tc.start.add(tc.key, tc.val)
        assert.Equal(t, tc.start, tc.expected)
    }
}

This approach, however, requires redundant testing logic for each function. The essence of generic types lies in their ability to work with arbitrary types, and constraints ensure that such types support the same operations.

Instead of excessively testing different types, it is more prudent to focus on testing only those types that exhibit distinct behaviors when using operators. For instance, the " " operator has different meanings for numbers (summation) and strings (concatenation), or the "<" and ">" operators have different interpretations for numbers (greater/lesser) and strings (lexicographical order).

To further illustrate this issue, developers should refer to a similar discussion where the user attempted to perform table testing with generic functions.

The above is the detailed content of How Can We Efficiently Table Test Go Generic Functions with Different Type Arguments?. For more information, please follow other related articles on the PHP Chinese website!