ギはGinkgoのギ

Transcript

1. ギはGinkgoのギ
2. 自己紹介 • 木内 智史 ◦ twitter: @8823scholar • スキルセット ◦ ruby、php、python、go、java、c++、c#、typescript、unity ◦ terraform • 趣味 ◦ 麻雀 ◦ スノーボード ◦ 投資 • 好きなテストフレームワーク ◦ rspec
3. Ginkgoとは？
4. go製のテスティングフレームワーク RSpecのgoリプレイス
5. RSpecとは？
6. ruby製のBDDフレームワーク TDDをより生産的で楽しくする！
7. TDD？BDD？
8. TDD？ “Test” Driven Development (テスト駆動開発) 「まずはテストを書こう」という開発手法 実装は後にして、まずは期待する挙動をテストとして先に書いてしまう。 その後、テストが通るように実装を書く。
9. TDDの何がいいの？ • 「テストを書く」という事が習慣づく • テストがコード資産として積み上がる • 「テストがない」という状態に居心地の悪さを感じるようになる • さらにテストを書くようになっていく コードがより堅牢になっていく
10. BDD？ “Behavior” Driven Development (振る舞い駆動開発) 「まずはテストを書く」という発想をより深く掘り下げて、 「まずは振る舞いを書く」という意識まで昇華させた呼び方。
11. BDD？ “Behavior” Driven Development (振る舞い駆動開発) 「まずはテストを書く」という発想をより深く掘り下げて、 「まずは振る舞いを書く」という意識まで昇華させた呼び方。 振る舞いって何よ？
12. 振る舞いって何よ？ • 何が
13. 振る舞いって何よ？ • 何が • どういう状況下で
14. 振る舞いって何よ？ • 何が • どういう状況下で • どうなるのか
15. 振る舞いって何よ？ • 何が • どういう状況下で • どうなるのか これらを先に書いていくのが 振る舞い駆動開発！
16. うーん、よくわからん
17. 普通のテストと何がどう違うの？
18. よろしい ならば戦争実際のコードを見てみよう
19. 要件 麻雀の牌姿を文字列で受け取り 点数を返す関数
20. 従来のテスト (testing.T) package main import ( "testing" "github.com/stretchr/testify/assert" ) func TestCalcPoint(t *testing.T) { for _, tc := range []struct { name string text string oya bool tsumo bool res []int err error }{ { name: "タンヤオ", text: "s222678m333456p8 8", oya: false, tsumo: false, res: []int{1300}, err: nil, }, } { t.Run(tc.name, func(t *testing.T) { res, err := CalcPoint(tc.text, tc.oya, tc.tsumo) assert.Equal(t, tc.res, res) assert.Equal(t, tc.err, err) }) } }
21. これはこれでいい、だがしかし • テストケースの条件が増えた時、条件と実際の呼び出し部分とに大きな距 離が開いてしまう • いったいなんのテストを書いているのか分からなくなる • テストケースの構造体以上の表現力を持てない • テストケースの書き方に制限はなく、それぞれが書きたいように書いてしま う
22. BDD的テスト (ginkgo) package main import ( . "github.com/onsi/ginkgo" . "github.com/onsi/gomega" ) var _ = Describe("CalcPoint", func() { var text string var tsumo bool = false Context("タンヤオロン", func() { BeforeEach(func() { text = "s222678m333456p8 8" }) Context("子", func() { It("should be 1300", func() { Expect(CalcPoint(text, false, tsumo)).To(Equal(1300)) }) }) Context("親", func() { It("should be 2000", func() { Expect(CalcPoint(text, true, tsumo)).To(Equal(2000)) }) }) }) })
23. テスト対象が俯瞰しやすくなる！ • Describe: テスト対象 • Context: 条件の違い • It: 期待する動作 これらの単語を用いて表現していくので、テスト対象や、その条件などを把握し やすくなる
24. つまり 呼び方や、書き方を変えただけ？
25. その通り！
26. but 「その、書き方が重要なんだ」 という強い意思が RSpecやGinkgoを作った
27. 「テストを書く」 「スペック(仕様)を書く」
28. BDDの世界へようこそ
29. ありがとうございました [参考文献] スはスペックのス https://magazine.rubyist.net/articles/0021/0021-Rspec.html