Comment pouvons-nous tester efficacement les fonctions génériques Go avec différents arguments de type ?

Table de test des fonctions génériques Go

Dans Go 1.18, les programmeurs peuvent profiter de sa nouvelle fonctionnalité générique. En explorant cette nouvelle fonctionnalité, les développeurs peuvent rencontrer des difficultés lors de la réalisation de tests de tables. L'un de ces défis est exploré dans cette discussion, en particulier dans le contexte du test de fonctions génériques avec des données de table.

Le problème se pose lorsque l'on tente d'instancier des fonctions génériques avec différents types d'arguments lors des tests de table. Pour résoudre ce problème, les développeurs ont souvent recours à une redéclaration de la logique de test pour chaque fonction, comme en témoigne l'extrait de code suivant :

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)
    }
}

Cette approche nécessite toutefois une logique de test redondante pour chaque fonction. L'essence des types génériques réside dans leur capacité à travailler avec des types arbitraires, et les contraintes garantissent que ces types prennent en charge les mêmes opérations.

Au lieu de tester excessivement différents types, il est plus prudent de se concentrer sur les tests de ces types uniquement. qui présentent des comportements distincts lors de l’utilisation d’opérateurs. Par exemple, l'opérateur " " a des significations différentes pour les nombres (sommation) et les chaînes (concaténation), ou le "" les opérateurs ont des interprétations différentes pour les nombres (supérieur/inférieur) et les chaînes (ordre lexicographique).

Pour illustrer davantage ce problème, les développeurs doivent se référer à une discussion similaire dans laquelle l'utilisateur a tenté d'effectuer des tests de table avec des fonctions génériques.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!