テストしやすいGoコードのデザイン

テストしやすいGoコードのデザイン golang.tokyo #2 12 December 2016 Taichi Nakashima 言いたいこと 明示的であれ！ 2 whoami @deeeet / @tcnksm (GitHub) http://deeeet.com A PaaS Dev&Ops (Using go for CLI tool, API, Batch jobs) 3 OSS Tools gcli - The easy way to build Golang command-line application ghr - Create Github Release and upload artifacts in parallel Packages go-httpstat - Go package for tracing golang HTTP request latency

[mattn]

良い資料。golang 使いは一度は目を通しておいた方がいい。

[wordi]

interfaceを渡すようにしてTest関数で完結するUnitテストに対応させる、ダックタイピングができる言語の強み、これを従来のOOP言語でやろうとするとabstractクラスをわざわざ用意して云々とめんどくさくなる

[igtm]

“Go best practices, six years in”

[shuzo_kino]

GoLangでテストやるときに気をつけること。ここでも変な拡張使わず生のtest使うのが推奨されてる。あとはグローバル変数や設定変数、標準入出力やコマンドライン引数の取扱いなど

[shag]

この資料がインターネットで無料で読めるとは！いい時代だ。

[luccafort]

めっちゃいい資料だった。以前このウンコードなんとかしたいなーと思っていたときにこれを読みたかった…。

[ono_matope]

最高だ

[tofu-kun]

今読み直すと、理解できる。良いスライド。

[yutaka_kinjyo]

ほほー！なるほど。

[kasumani]

テストしやすいGoコードのデザイン ステータスコードを「返り値として返す」関数を定義する． ただし今のままでは明確な「入力がない」ため`Run`関数をテストできない． Tags: from Pocket December 14, 2016 at 08:14AM via IFTTT

[jojo800]

具体例豊富で参考になる

[cl-gaku]

最高にわかりやすい

[hoihoi225]

go言語

[niconegoto]

これは必見の技術

[loosefingers]

最高だ、

[keepkeptkept]

とても良いまとめ。

[akatakun]

Table Driven Testに落とし込めるまで分解する，`os.Exit`（もしくはそれを暗黙的に呼ぶ`log.Fatal`）はあまり使うべきではない(deferが実行されないため)

[FumblePerson]

途中まで呼んだけど、とても良かった。結構長いのであとで全部読む。

[ko-ya-ma]

けっこうな分量があるけれど、分かりやすくて実践的

[yuitang]

Go関係無くみんな読むべき資料だった

[zetamatta]

グローバル変数を使わないのは当然として、標準入出力・環境変数など、切り替え出来ない入出力先の固定化を避けるのが大切か

[restartr]

とてもわかりやすい👍/E2Eテスト…って思ったけどピラミッド下のリンク先資料がめっちゃよかった

[y-kawaz]

スマホで縦向きで見れないスライドシステム…

[escape_artist]

良すぎる

[masaru_b_cl]

どんな言語でもUnitテストの基本はおんなじなんだなぁ

[raimon49]

いかにTable Driven Testへ落とし込めるように設計するか。I/Oを抽象化し、void的な関数を避ける。

[baronhorse]

testing だけは辛い

[t-wada]

ユニットテスト容易性を向上させるコード設計とはどういうものかを、Go のコードを通じて説明している

[catatsuy]

良すぎる

[moshisora]

大作だった…。あと読む。

[azihsoyn]

大作だった