Winery exercice - Partie 4

Dans la partie 3, on a trié la cave sans jamais toucher à l’originale, et on a démonté le mythe du tri « stable par hasard ».
On s’était quitté sur une dernière promesse : Search, filtrer la cave sur le nom, la région et l’année.
C’est le quatrième et dernier test du Winery exercice. Le plus court à écrire… et celui qui cache le plus de pièges de typage. 🍷

💡 Tout le code est sur GitHub : pcavezzan/2026-july-technical-interview-sample, branche result/winery.

🎯 Ce que le test attend

Search prend une chaîne et renvoie une Cellar avec tous les vins qui la contiennent, dans le nom, la région ou l’année :

func TestSearchWines(t *testing.T) {
    cellar := openWineCatalog(t)
    assert.Equal(t, 6, cellar.Length())

    res1 := cellar.Search("")
    assert.Equal(t, "0,1,2,3,4,5", res1.dump())

    res2 := cellar.Search("cru")
    assert.Equal(t, "1,4,5", res2.dump())

    res3 := cellar.Search("bord")
    assert.Equal(t, "0,2,3", res3.dump())

    res4 := cellar.Search("88")
    assert.Equal(t, "0,3", res4.dump())

    res5 := cellar.Search("AUX")
    assert.Equal(t, "0,2,3", res5.dump())
}

Reprenons le catalogue, c’est la clé pour lire les assertions :

Chaque assertion isole une exigence, et à elles cinq elles dessinent tout le cahier des charges :

• "" ressort tout. La chaîne vide est contenue dans n’importe quelle chaîne, donc les 6 vins remontent. Pas de cas particulier à écrire : c’est un cadeau du strings.Contains, à condition de ne pas le court-circuiter. 🎁
• "cru" touche le nom des vins 1, 4 et 5, dont le Cru majuscule du vin 5. Premier signal : la recherche est insensible à la casse.
• "bord" tape dans la région Bordeaux (vins 0, 2, 3). On cherche donc bien sur plusieurs champs, pas seulement le nom.
• "AUX" retrouve Bordeaux, en majuscules cette fois. La casse ne doit décidément jamais compter. 🎯
• "88" sort l’année 1988 (vins 0 et 3). Et là, piège : Year est un int, pas une string. On cherche une sous-chaîne dans un entier. 🪤

🧩 Le point de départ (code fourni)

// Search returns wine that matches the search terms on below wine properties
// - Name
// - Region
// - Year
// Note that the search implementation must be case insensitive
func (c Cellar) Search(str string) Cellar {
    var res Cellar

    // TODO: Candidate Codes

    return res
}

Le squelette est le plus honnête de la série : même le commentaire prévient que la recherche doit être insensible à la casse.
Reste à ne pas se faire avoir par les deux détails que le commentaire ne dit pas. 👇

🛠️ Le réflexe naturel… et les deux vins qui manquent

Le premier jet, celui qu’on écrit sans réfléchir : on boucle, on teste strings.Contains sur chaque champ.

func (c Cellar) Search(str string) Cellar {
    var res Cellar
    for _, wine := range c {
        if strings.Contains(wine.Name, str) ||
            strings.Contains(wine.Region, str) {
            res = append(res, wine)
        }
    }
    return res
}

Deux problèmes, et le compilateur n’en signale aucun.

1️⃣ La casse.
strings.Contains("Fourchaume - Chablis 1er Cru", "cru") est faux : Cru porte une majuscule.
Et strings.Contains("Bordeaux", "AUX") l’est tout autant. Les recherches "cru" et "AUX" rendraient des résultats incomplets.

2️⃣ L’année manquante.
On ne peut même pas écrire strings.Contains(wine.Year, str) : wine.Year est un int, et strings.Contains attend deux string. Ça ne compile pas. La recherche "88" n’a aucune chance de sortir les vins 0 et 3.

🛠️ Le fix : normaliser la casse, stringifier l’année

func (c Cellar) Search(str string) Cellar {
    var res Cellar
    searchTerm := strings.ToLower(str)
    for _, wine := range c {
        if strings.Contains(strings.ToLower(wine.Name), searchTerm) ||
            strings.Contains(strings.ToLower(wine.Region), searchTerm) ||
            strings.Contains(strconv.Itoa(wine.Year), searchTerm) {
            res = append(res, wine)
        }
    }
    return res
}

Trois gestes, et les trois cas retombent sur leurs pieds :

• strings.ToLower des deux côtés. On abaisse la casse du terme recherché une seule fois (searchTerm), puis celle de chaque champ. "AUX" devient "aux", "Bordeaux" devient "bordeaux", et la sous-chaîne se retrouve. 🧼
• strconv.Itoa(wine.Year) transforme l’entier 1988 en "1988", dans lequel strings.Contains retrouve "88". La recherche sur l’année redevient une recherche de sous-chaîne comme les autres.
• La chaîne vide reste gérée gratuitement. strings.Contains(x, "") vaut true pour tout x, donc Search("") renvoie les 6 vins sans qu’on écrive quoi que ce soit.

Quatre tests au vert. Le Winery exercice est bouclé. 🎉

🥊 L’aparté du jour : « insensible à la casse » ne veut pas dire « insensible aux accents »

Le commentaire du squelette demandait une recherche case insensitive.
On l’a rendue telle avec strings.ToLower mais dans une vraie cave, un utilisateur qui tape "tache" s’attend à trouver « La tâche grand cru », et "romanee" à trouver « Romanée ». Or ToLower ne défait pas les diacritiques : â reste â, é reste é.

Le remède idiomatique passe par golang.org/x/text. On décompose (forme NFD), on retire la catégorie des marques diacritiques, on recompose :

import (
    "golang.org/x/text/runes"
    "golang.org/x/text/transform"
    "golang.org/x/text/unicode/norm"
    "unicode"
)

// fold abaisse la casse ET retire les accents : "La tâche" -> "la tache"
func fold(s string) string {
    t := transform.Chain(
        norm.NFD,                                // é -> e + ´
        runes.Remove(runes.In(unicode.Mn)),      // supprime les marques (Mn)
        norm.NFC,                                // recompose
    )
    out, _, _ := transform.String(t, s)
    return strings.ToLower(out)
}

Avec fold à la place de strings.ToLower, Search("tache") retrouverait enfin le vin 4.

Retrouver un exemple d’implémentation case-sensitive ici

🧪 Rendre le test à la hauteur des trois précédents

Comme dans les parties 1 à 3, TestSearchWines traîne les mêmes petits défauts, et se prête idéalement au table testing.

assert là où require s’impose

cellar := openWineCatalog(t)
assert.Equal(t, 6, cellar.Length())

Rebelote : cellar.Length() == 6 est le prérequis de tout le reste. Si le catalogue ne contient pas 6 vins, les cinq résultats attendus ("0,1,2,3,4,5", "1,4,5"…) décrivent des indices qui n’ont plus de sens. Un require.Equal coupe net au lieu de dérouler une cascade d’échecs illisibles.

La forme table-driven

Les cinq recherches ne sont que cinq lignes d’un même tableau (entrée → ids attendus). C’est le cas d’école du table testing : chaque cas isolé, chaque intention nommée.

func TestSearchWines(t *testing.T) {
    t.Parallel()

    tests := []struct {
        name  string
        query string
        want  string
    }{
        {name: "chaîne vide : toute la cave", query: "", want: "0,1,2,3,4,5"},
        {name: "sur le nom (Cru, casse mélangée)", query: "cru", want: "1,4,5"},
        {name: "sur la région (Bordeaux)", query: "bord", want: "0,2,3"},
        {name: "sur l'année (sous-chaîne de 1988)", query: "88", want: "0,3"},
        {name: "insensible à la casse (AUX)", query: "AUX", want: "0,2,3"},
    }

    cellar := openWineCatalog(t)
    require.Equal(t, 6, cellar.Length())

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel()

            got := cellar.Search(tt.query)
            assert.Equal(t, tt.want, got.dump())
        })
    }
}

💡 La version table-driven complète est visible sur la branche result/winery.

✅ Résultat

Une poignée de lignes, et le dernier test passe. Search n’avait rien de sorcier une fois les deux pièges vus : normaliser la casse des deux côtés, et convertir l’année en chaîne avant de la chercher. Le reste, strings.Contains s’en charge tout seul, jusqu’à la chaîne vide qui ressort tout le catalogue sans le moindre cas particulier.

La vraie leçon de cette manche est en creux : « insensible à la casse » et « chercher dans un entier » sont deux formulations qui masquent des décisions de sémantique (accents, égalité ou sous-chaîne) que le test ne pose pas, mais qu’un vrai produit devra trancher.

🍷 Le mot de la fin de la série

Quatre tests, quatre pièges, et un fil rouge : en Go, le typage du domaine et les valeurs par défaut font une partie du travail… à condition de savoir où ils s’arrêtent.

• Partie 1 — l’aller-retour JSON et la valeur zéro qui vaut « absent ».
• Partie 2 — la map nil qui panique en écriture, pas en lecture.
• Partie 3 — le slice qui partage son tableau, et le tri « stable par chance ».
• Partie 4 — la casse, les accents, et la recherche dans un entier.

Aucun de ces tests n’est difficile. Ce qui les rend instructifs, c’est qu’ils échouent tous silencieusement sur le premier réflexe, puis se réparent en une ou deux lignes une fois le mécanisme compris. C’est exactement ce qu’un exercice technique devrait faire : révéler ce qu’on croyait savoir. 🍇

Merci de m’avoir suivi sur ces quatre manches. À bientôt ! 🥂

📎 Annexe : Unicode et le piège du « é » à deux visages

s1 := "café"        // NFC : le é en un seul code point
s2 := "cafe\u0301"  // NFD : e + accent aigu combinant (forcé décomposé)

s1 == s2            // false
len(s1) == len(s2)  // false : 5 octets contre 6

import "golang.org/x/text/unicode/norm"

s1 := "café"
s2 := "cafe\u0301"  // même mot, forme décomposée

norm.NFC.String(s1) == norm.NFC.String(s2)  // true

ALTER TABLE articles
    ADD COLUMN title_freesearch TEXT
    GENERATED ALWAYS AS (lower(unaccent(title_freesearch))) STORED;

CREATE INDEX articles_title_freesearch_trgm_idx
    ON articles USING gin (title_freesearch gin_trgm_ops);