J'apprends Go en codant un petit projet personnel. Même si c'est petit, j'ai décidé de faire des tests unitaires rigoureux pour apprendre de bonnes habitudes sur Go dès le début.

Les tests unitaires triviaux étaient tous très bien, mais je suis maintenant perplexe avec les dépendances; Je veux pouvoir remplacer certains appels de fonction par des faux. Voici un extrait de mon code:

func get_page(url string) string {
    get_dl_slot(url)
    defer free_dl_slot(url)

    resp, err := http.Get(url)
    if err != nil { return "" }
    defer resp.Body.Close()

    contents, err := ioutil.ReadAll(resp.Body)
    if err != nil { return "" }
    return string(contents)
}

func downloader() {
    dl_slots = make(chan bool, DL_SLOT_AMOUNT) // Init the download slot semaphore
    content := get_page(BASE_URL)
    links_regexp := regexp.MustCompile(LIST_LINK_REGEXP)
    matches := links_regexp.FindAllStringSubmatch(content, -1)
    for _, match := range matches{
        go serie_dl(match[1], match[2])
    }
}

J'aimerais pouvoir tester downloader () sans réellement obtenir une page via http - c'est-à-dire en se moquant soit de get_page (plus facile car il ne renvoie que le contenu de la page sous forme de chaîne) soit de http.Get ().

J'ai trouvé ce fil: https://groups.google.com/forum/#!topic/golang-nuts/6AN1E2CJOxI qui semble concerner un problème similaire. Julian Phillips présente sa bibliothèque, Withmock ( http://github.com/qur/withmock ) comme une solution, mais je ne parviens pas à la faire fonctionner. Voici les parties pertinentes de mon code de test, qui est en grande partie un code culte pour moi, pour être honnête:

import (
    "testing"
    "net/http" // mock
    "code.google.com/p/gomock"
)
...
func TestDownloader (t *testing.T) {
    ctrl := gomock.NewController()
    defer ctrl.Finish()
    http.MOCK().SetController(ctrl)
    http.EXPECT().Get(BASE_URL)
    downloader()
    // The rest to be written
}

La sortie de test est la suivante:

ERROR: Failed to install '_et/http': exit status 1
output:
can't load package: package _et/http: found packages http (chunked.go) and main (main_mock.go) in /var/folders/z9/ql_yn5h550s6shtb9c5sggj40000gn/T/withmock570825607/path/src/_et/http

Le Withmock est-il une solution à mon problème de test? Que dois-je faire pour le faire fonctionner?

Bravo à vous pour avoir pratiqué de bons tests! :)

Personnellement, je n'utilise pas gomock(ni aucun framework moqueur d'ailleurs; se moquer dans Go est très facile sans cela). Je passerais une dépendance à la downloader()fonction en tant que paramètre, ou je créerais downloader()une méthode sur un type, et le type peut contenir la get_pagedépendance:

Méthode 1: passer get_page()comme paramètre dedownloader()

type PageGetter func(url string) string

func downloader(pageGetterFunc PageGetter) {
    // ...
    content := pageGetterFunc(BASE_URL)
    // ...
}

Principale:

func get_page(url string) string { /* ... */ }

func main() {
    downloader(get_page)
}

Tester:

func mock_get_page(url string) string {
    // mock your 'get_page()' function here
}

func TestDownloader(t *testing.T) {
    downloader(mock_get_page)
}

Méthode 2: créer download()une méthode d'un type Downloader:

Si vous ne souhaitez pas passer la dépendance en tant que paramètre, vous pouvez également créer get_page()un membre d'un type et créer download()une méthode de ce type, qui peut ensuite utiliser get_page:

type PageGetter func(url string) string

type Downloader struct {
    get_page PageGetter
}

func NewDownloader(pg PageGetter) *Downloader {
    return &Downloader{get_page: pg}
}

func (d *Downloader) download() {
    //...
    content := d.get_page(BASE_URL)
    //...
}

Principale:

func get_page(url string) string { /* ... */ }

func main() {
    d := NewDownloader(get_page)
    d.download()
}

Tester:

func mock_get_page(url string) string {
    // mock your 'get_page()' function here
}

func TestDownloader() {
    d := NewDownloader(mock_get_page)
    d.download()
}

Si vous modifiez la définition de votre fonction pour utiliser une variable à la place:

var get_page = func(url string) string {
    ...
}

Vous pouvez le remplacer dans vos tests:

func TestDownloader(t *testing.T) {
    get_page = func(url string) string {
        if url != "expected" {
            t.Fatal("good message")
        }
        return "something"
    }
    downloader()
}

Attention cependant, vos autres tests peuvent échouer s'ils testent la fonctionnalité de la fonction que vous remplacez!

Les auteurs de Go utilisent ce modèle dans la bibliothèque standard Go pour insérer des crochets de test dans le code afin de faciliter les tests:

https://golang.org/src/net/hook.go

https://golang.org/src/net/dial.go#L248

https://golang.org/src/net/dial_test.go#L701

J'utilise une approche légèrement différente où les méthodes de struct public implémentent des interfaces mais leur logique se limite à simplement envelopper les fonctions privées (non exportées) qui prennent ces interfaces comme paramètres. Cela vous donne la granularité dont vous auriez besoin pour vous moquer de pratiquement toutes les dépendances tout en disposant d'une API propre à utiliser depuis l'extérieur de votre suite de tests.

Pour comprendre cela, il est impératif de comprendre que vous avez accès aux méthodes non exportées dans votre cas de test (c'est-à-dire à partir de vos _test.gofichiers) afin que vous les testiez au lieu de tester celles exportées qui n'ont pas de logique à l'intérieur de l'emballage.

Pour résumer: testez les fonctions non exportées au lieu de tester celles exportées!

Faisons un exemple. Supposons que nous ayons une structure d'API Slack qui a deux méthodes:

• la SendMessageméthode qui envoie une requête HTTP à un webhook Slack
• la SendDataSynchronouslyméthode qui a donné une tranche de chaînes les itère et appelle SendMessageà chaque itération

Donc, pour tester SendDataSynchronouslysans faire de requête HTTP à chaque fois, il faudrait se moquer SendMessage, non?

package main

import (
    "fmt"
)

// URI interface
type URI interface {
    GetURL() string
}

// MessageSender interface
type MessageSender interface {
    SendMessage(message string) error
}

// This one is the "object" that our users will call to use this package functionalities
type API struct {
    baseURL  string
    endpoint string
}

// Here we make API implement implicitly the URI interface
func (api *API) GetURL() string {
    return api.baseURL + api.endpoint
}

// Here we make API implement implicitly the MessageSender interface
// Again we're just WRAPPING the sendMessage function here, nothing fancy 
func (api *API) SendMessage(message string) error {
    return sendMessage(api, message)
}

// We want to test this method but it calls SendMessage which makes a real HTTP request!
// Again we're just WRAPPING the sendDataSynchronously function here, nothing fancy
func (api *API) SendDataSynchronously(data []string) error {
    return sendDataSynchronously(api, data)
}

// this would make a real HTTP request
func sendMessage(uri URI, message string) error {
    fmt.Println("This function won't get called because we will mock it")
    return nil
}

// this is the function we want to test :)
func sendDataSynchronously(sender MessageSender, data []string) error {
    for _, text := range data {
        err := sender.SendMessage(text)

        if err != nil {
            return err
        }
    }

    return nil
}

// TEST CASE BELOW

// Here's our mock which just contains some variables that will be filled for running assertions on them later on
type mockedSender struct {
    err      error
    messages []string
}

// We make our mock implement the MessageSender interface so we can test sendDataSynchronously
func (sender *mockedSender) SendMessage(message string) error {
    // let's store all received messages for later assertions
    sender.messages = append(sender.messages, message)

    return sender.err // return error for later assertions
}

func TestSendsAllMessagesSynchronously() {
    mockedMessages := make([]string, 0)
    sender := mockedSender{nil, mockedMessages}

    messagesToSend := []string{"one", "two", "three"}
    err := sendDataSynchronously(&sender, messagesToSend)

    if err == nil {
        fmt.Println("All good here we expect the error to be nil:", err)
    }

    expectedMessages := fmt.Sprintf("%v", messagesToSend)
    actualMessages := fmt.Sprintf("%v", sender.messages)

    if expectedMessages == actualMessages {
        fmt.Println("Actual messages are as expected:", actualMessages)
    }
}

func main() {
    TestSendsAllMessagesSynchronously()
}

Ce que j'aime dans cette approche, c'est qu'en regardant les méthodes non exportées, vous pouvez clairement voir quelles sont les dépendances. En même temps, l'API que vous exportez est beaucoup plus propre et avec moins de paramètres à transmettre puisque la vraie dépendance ici est juste le récepteur parent qui implémente toutes ces interfaces lui-même. Pourtant, chaque fonction ne dépend potentiellement que d'une partie de celle-ci (une, peut-être deux interfaces), ce qui rend les refacteurs beaucoup plus faciles. C'est bien de voir comment votre code est vraiment couplé rien qu'en regardant les signatures des fonctions, je pense que cela fait un outil puissant contre l'odeur de code.

Pour simplifier les choses, je mets tout dans un seul fichier pour vous permettre d'exécuter le code dans le terrain de jeu ici mais je vous suggère également de consulter l'exemple complet sur GitHub, voici le fichier slack.go et ici le slack_test.go .

Et voici le tout :)

Je ferais quelque chose comme,

Principale

var getPage = get_page
func get_page (...

func downloader() {
    dl_slots = make(chan bool, DL_SLOT_AMOUNT) // Init the download slot semaphore
    content := getPage(BASE_URL)
    links_regexp := regexp.MustCompile(LIST_LINK_REGEXP)
    matches := links_regexp.FindAllStringSubmatch(content, -1)
    for _, match := range matches{
        go serie_dl(match[1], match[2])
    }
}

Tester

func TestDownloader (t *testing.T) {
    origGetPage := getPage
    getPage = mock_get_page
    defer func() {getPage = origGatePage}()
    // The rest to be written
}

// define mock_get_page and rest of the codes
func mock_get_page (....

Et _j'éviterais en golang. Mieux vaut utiliser camelCase

Avertissement: cela peut augmenter un peu la taille du fichier exécutable et coûter un peu en termes de performances d'exécution. OMI, ce serait mieux si golang avait une fonctionnalité telle que le décorateur de macro ou de fonction.

Si vous souhaitez simuler des fonctions sans changer son API, le moyen le plus simple est de modifier un peu l'implémentation:

func getPage(url string) string {
  if GetPageMock != nil {
    return GetPageMock()
  }

  // getPage real implementation goes here!
}

func downloader() {
  if GetPageMock != nil {
    return GetPageMock()
  }

  // getPage real implementation goes here!
}

var GetPageMock func(url string) string = nil
var DownloaderMock func() = nil

De cette façon, nous pouvons réellement simuler une fonction parmi les autres. Pour plus de commodité, nous pouvons fournir un tel passe-partout moqueur:

// download.go
func getPage(url string) string {
  if m.GetPageMock != nil {
    return m.GetPageMock()
  }

  // getPage real implementation goes here!
}

func downloader() {
  if m.GetPageMock != nil {
    return m.GetPageMock()
  }

  // getPage real implementation goes here!
}

type MockHandler struct {
  GetPage func(url string) string
  Downloader func()
}

var m *MockHandler = new(MockHandler)

func Mock(handler *MockHandler) {
  m = handler
}

Dans le fichier de test:

// download_test.go
func GetPageMock(url string) string {
  // ...
}

func TestDownloader(t *testing.T) {
  Mock(&MockHandler{
    GetPage: GetPageMock,
  })

  // Test implementation goes here!

  Mock(new(MockHandler)) // Reset mocked functions
}

Étant donné que le test unitaire est le domaine de cette question, nous vous recommandons vivement d'utiliser https://github.com/bouk/monkey . Ce package vous permet de simuler un test sans changer votre code source d'origine. Comparé à une autre réponse, c'est plus "non intrusif"。

PRINCIPALE

type AA struct {
 //...
}
func (a *AA) OriginalFunc() {
//...
}

TEST DE SIMULATION

var a *AA

func NewFunc(a *AA) {
 //...
}

monkey.PatchMethod(reflect.TypeOf(a), "OriginalFunc", NewFunc)

Le mauvais côté est:

- Rappelé par Dave.C, cette méthode n'est pas sûre. Ne l'utilisez donc pas en dehors du test unitaire.

- Est-ce que Go est non idiomatique.

Le bon côté est:

++ Est non intrusif. Vous faire faire les choses sans changer le code principal. Comme l'a dit Thomas.

++ Vous faire changer le comportement du package (peut-être fourni par un tiers) avec le moins de code.