私は小さな個人プロジェクトをコーディングすることで囲碁を学んでいます。小さいながら、厳密なユニットテストを行って、最初からGoの良い習慣を学ぶことにしました。

ささいな単体テストはすべて上手くできていましたが、今は依存関係に困惑しています。一部の関数呼び出しをモック呼び出しに置き換えられるようにしたい。これが私のコードのスニペットです：

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

実際にhttp経由でページを取得せずに、つまりget_page（ページコンテンツのみを文字列として返すため、より簡単）またはhttp.Get（）をモックすることで、downloader（）をテストできるようにしたいと思います。

私はこのスレッドを見つけました：https : //groups.google.com/forum/#!topic / golang-nuts / 6AN1E2CJOxIこれは同様の問題についてのようです。Julian Phillipsが彼のライブラリであるWithmock（http://github.com/qur/withmock）をソリューションとして提示していますが、私はそれを動作させることができません。正直に言うと、私にとっては主にカーゴカルトコードである私のテストコードの関連部分です：

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
}

テスト出力は次のとおりです。

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

Withmockは私のテスト問題の解決策ですか？それを機能させるにはどうすればよいですか？

良いテストを実践してくれてありがとう。:)

個人的には、私は使用していませんgomock（またはそのためのモックフレームワークはありません。Goでのモックは非常に簡単です）。downloader()関数に依存関係をパラメーターとして渡すかdownloader()、型にメソッドを作成し、型がget_page依存関係を保持できるようにします。

方法1：get_page()のパラメーターとして渡すdownloader()

type PageGetter func(url string) string

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

メイン：

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

func main() {
    downloader(get_page)
}

テスト：

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

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

download()方法2：タイプのメソッドを作成しDownloaderます。

依存関係をパラメーターとして渡したくない場合get_page()は、型のメンバーを作成しdownload()、その型のメソッドを作成して、以下を使用することもできます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)
    //...
}

メイン：

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

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

テスト：

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

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

代わりに変数を使用するように関数定義を変更した場合：

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

あなたはテストでそれを上書きすることができます：

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

ただし、他のテストは、オーバーライドする関数の機能をテストすると失敗する可能性があります。

Goの作成者は、Go標準ライブラリでこのパターンを使用して、コードにテストフックを挿入し、テストを容易にします。

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

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

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

私は少し異なるアプローチを使用していますが、パブリック structメソッドはインターフェイスを実装しますが、それらのロジックは、これらのインターフェイスをパラメーターとして受け取るプライベート（非エクスポート）関数のラップに限定されます。これにより、実質的にすべての依存関係をモックする必要があり、しかもテストスイートの外部から使用するためのクリーンなAPIが必要になります。

これを理解するには、テストケースで（つまり、_test.goファイル内から）エクスポートされていないメソッドにアクセスできることを理解することが不可欠です。そのため、ラッピングの内側にロジックがないエクスポートされたメソッドをテストする代わりに、それらをテストします。

要約すると、エクスポートされた関数をテストする代わりに、エクスポートされていない関数をテストしてください！

例を作ってみましょう。2つのメソッドを持つSlack API構造体があるとします。

• SendMessageスラックウェブフックにHTTPリクエストを送信する方法
• SendDataSynchronouslyそれらの上に文字列を反復処理のスライスを与えられ、呼び出すメソッドSendMessageすべての反復のために

したがって、SendDataSynchronously毎回HTTPリクエストを行わずにテストするには、モックする必要がありSendMessageますよね？

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

このアプローチについて私が気に入っているのは、エクスポートされていないメソッドを見ると、依存関係が明確にわかることです。同時に、エクスポートするAPIは非常にクリーンで、渡すパラメーターが少なくなります。これは、ここでの真の依存関係が、それらのすべてのインターフェイス自体を実装している親レシーバーにすぎないためです。しかし、すべての機能は潜在的にその一部（1つ、おそらく2つのインターフェース）にのみ依存しているため、リファクタリングがはるかに簡単になります。関数のシグネチャを見るだけで、コードが実際にどのように結合されているかを確認できるのは素晴らしいことです。コードの臭いに対して強力なツールになると思います。

物事を簡単にするために、ここでは遊び場でコードを実行できるようにすべてを1つのファイルに入れますが、GitHubで完全な例も確認することをお勧めします。ここにslack.goファイルとここにslack_test.goがあります。

そしてここですべて:)

私は次のようなことをします、

メイン

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

テスト

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

そして、私は_golangでは避けます。camelCaseをより効果的に使用する

警告：これにより、実行可能ファイルのサイズが少し大きくなり、実行時のパフォーマンスが少し低下する可能性があります。IMO、これはgolangにマクロや関数デコレーターなどの機能がある場合に適しています。

APIを変更せずに関数をモックしたい場合、最も簡単な方法は実装を少し変更することです：

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

このようにして、ある機能を他の機能から実際に模倣することができます。より便利にするために、そのようなあざける定型文を提供できます。

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

テストファイル：

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

ユニットテストがこの質問のドメインであると考えると、https：//github.com/bouk/monkeyを使用することを強くお勧めします。このパッケージを使用すると、元のソースコードを変更せずに模擬テストを行うことができます。他の回答と比較すると、より「非侵入型」です。

メイン

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

模擬試験

var a *AA

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

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

悪い面は：

-Dave.Cにより指摘された、このメソッドは安全ではありません。したがって、単体テスト以外では使用しないでください。

-非慣用的な囲碁です。

良い面は：

++は邪魔にならない。メインコードを変更せずに物事を行うようにします。トーマスが言ったように。

++最小限のコードでパッケージの動作を変更する（サードパーティによって提供される場合があります）。