Uczę się Go, kodując mały, osobisty projekt. Mimo że jest mały, zdecydowałem się przeprowadzić rygorystyczne testy jednostkowe, aby od samego początku nauczyć się dobrych nawyków w Go.

Zwykłe testy jednostkowe były w porządku i eleganckie, ale teraz jestem zaintrygowany zależnościami; Chcę mieć możliwość zamiany niektórych wywołań funkcji na pozorowane. Oto fragment mojego kodu:

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

Chciałbym móc przetestować downloader () bez faktycznego pobierania strony przez http - tj. Przez mockowanie get_page (łatwiejsze, ponieważ zwraca tylko zawartość strony jako ciąg znaków) lub http.Get ().

Znalazłem ten wątek: https://groups.google.com/forum/#!topic/golang-nuts/6AN1E2CJOxI, który wydaje się być o podobnym problemie. Julian Phillips przedstawia swoją bibliotekę Withmock ( http://github.com/qur/withmock ) jako rozwiązanie, ale nie jestem w stanie zmusić go do działania. Oto odpowiednie części mojego kodu testowego, który jest dla mnie w dużej mierze kodem kultu cargo, szczerze mówiąc:

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
}

Wynik testu jest następujący:

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

Czy Withmock jest rozwiązaniem mojego problemu z testowaniem? Co mam zrobić, żeby to zadziałało?

Brawa dla Ciebie za wykonanie dobrych testów! :)

Osobiście nie używam gomock(ani żadnego mockującego frameworka; mockowanie w Go jest bardzo łatwe bez niego). Albo przekazałbym zależność do downloader()funkcji jako parametr, albo zrobiłbym downloader()metodę na typie, a typ może przechowywać get_pagezależność:

Metoda 1: Przekaż get_page()jako parametrdownloader()

type PageGetter func(url string) string

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

Główny:

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

func main() {
    downloader(get_page)
}

Test:

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

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

Method2: Utwórz download()metodę typu Downloader:

Jeśli nie chcesz przekazywać zależności jako parametru, możesz również utworzyć get_page()element członkowski typu i utworzyć download()metodę tego typu, która może następnie użyć 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)
    //...
}

Główny:

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

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

Test:

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

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

Jeśli zmienisz definicję funkcji, aby zamiast tego używała zmiennej:

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

Możesz to zmienić w swoich testach:

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

Ostrożnie, inne testy mogą się nie powieść, jeśli sprawdzą funkcjonalność funkcji, którą nadpisujesz!

Autorzy Go używają tego wzorca w bibliotece standardowej Go do wstawiania punktów zaczepienia testowego do kodu, aby ułatwić testowanie:

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

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

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

Używam nieco innego podejścia, w którym metody struktury publicznej implementują interfejsy, ale ich logika ogranicza się do pakowania prywatnych (niewyeksportowanych) funkcji, które przyjmują te interfejsy jako parametry. Daje to szczegółowość, której będziesz potrzebować, aby symulować praktycznie każdą zależność, a jednocześnie mieć czysty interfejs API do użytku spoza zestawu testów.

Aby to zrozumieć, konieczne jest zrozumienie, że masz dostęp do niewyeksportowanych metod w swoim przypadku testowym (tj. Z poziomu _test.goplików), więc testujesz je zamiast testować wyeksportowane, które poza opakowaniem nie mają w sobie żadnej logiki.

Podsumowując: przetestuj niewyeksportowane funkcje zamiast testować wyeksportowane!

Zróbmy przykład. Powiedzmy, że mamy strukturę Slack API, która ma dwie metody:

• SendMessagemetoda, która wysyła żądanie HTTP do webhook Slack
• SendDataSynchronouslymetoda który otrzymał kawałek ciągów iteracje nad nimi oraz wzywa SendMessagedo każdej iteracji

Aby więc testować SendDataSynchronouslybez wysyłania żądania HTTP za każdym razem, musielibyśmy kpić SendMessage, prawda?

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

W tym podejściu podoba mi się to, że patrząc na niezgłoszone metody, można wyraźnie zobaczyć, jakie są zależności. Jednocześnie eksportowany interfejs API jest dużo bardziej przejrzysty i zawiera mniej parametrów do przekazania, ponieważ prawdziwą zależnością jest tutaj tylko odbiornik nadrzędny, który sam implementuje wszystkie te interfejsy. Jednak każda funkcja jest potencjalnie zależna tylko od jednej jej części (jednego, może dwóch interfejsów), co znacznie ułatwia refaktory. Miło jest zobaczyć, jak Twój kod jest naprawdę połączony, po prostu patrząc na sygnatury funkcji, myślę, że jest to potężne narzędzie przeciwko wąchaniu kodu.

Aby ułatwić sprawę, umieściłem wszystko w jednym pliku, aby umożliwić uruchomienie kodu na placu zabaw tutaj, ale sugeruję również sprawdzenie pełnego przykładu na GitHub, tutaj jest plik slack.go , a tutaj slack_test.go .

A tu całość :)

Zrobiłbym coś takiego,

Główny

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

Test

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 (....

I unikałbym _w golang. Lepiej użyj camelCase

Ostrzeżenie: może to nieco zwiększyć rozmiar pliku wykonywalnego i obniżyć wydajność w czasie wykonywania. IMO, byłoby lepiej, gdyby golang miał taką funkcję jak makro lub dekorator funkcji.

Jeśli chcesz mockować funkcje bez zmiany ich API, najłatwiej jest trochę zmienić implementację:

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

W ten sposób możemy faktycznie wyszydzać jedną funkcję spośród innych. Dla wygodniejszego możemy dostarczyć takie szydercze schematy:

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

W pliku testowym:

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

Biorąc pod uwagę, że test jednostkowy jest domeną tego pytania, zdecydowanie zalecamy skorzystanie z https://github.com/bouk/monkey . Ten pakiet umożliwia testowanie próbne bez zmiany oryginalnego kodu źródłowego. W porównaniu z inną odpowiedzią, jest bardziej „nieinwazyjna”。

GŁÓWNY

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

TEST PRÓBNY

var a *AA

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

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

Zła strona to:

- Przypomniał Dave.C, Ta metoda jest niebezpieczna. Więc nie używaj go poza testem jednostkowym.

- Nie idiomatycznie Go.

Dobra strona to:

++ Nie inwazyjny. Spraw, abyś robił rzeczy bez zmiany głównego kodu. Jak powiedział Thomas.

++ Spraw, abyś zmienił zachowanie pakietu (może dostarczonego przez osobę trzecią) przy użyciu najmniejszego kodu.