ギはGinkgoのギ

自己紹介 • 木内智史 ◦ twitter: @8823scholar • スキルセット ◦
ruby、php、python、go、java、c++、c#、typescript、unity ◦ terraform • 趣味 ◦ 麻雀 ◦ スノーボード ◦ 投資 • 好きなテストフレームワーク ◦ rspec

Ginkgoとは？

go製のテスティングフレームワーク RSpecのgoリプレイス

RSpecとは？

ruby製のBDDフレームワーク TDDをより生産的で楽しくする！

TDD？BDD？

TDD？ “Test” Driven Development (テスト駆動開発) 「まずはテストを書こう」という開発手法実装は後にして、まずは期待する挙動をテストとして先に書いてしまう。その後、テストが通るように実装を書く。

TDDの何がいいの？ • 「テストを書く」という事が習慣づく • テストがコード資産として積み上がる • 「テストがない」という状態に居心地の悪さを感じるようになる • さらにテストを書くようになっていくコードがより堅牢になっていく

BDD？ “Behavior” Driven Development (振る舞い駆動開発) 「まずはテストを書く」という発想をより深く掘り下げて、「まずは振る舞いを書く」という意識まで昇華させた呼び方。

BDD？ “Behavior” Driven Development (振る舞い駆動開発) 「まずはテストを書く」という発想をより深く掘り下げて、「まずは振る舞いを書く」という意識まで昇華させた呼び方。振る舞いって何よ？

振る舞いって何よ？ • 何が

振る舞いって何よ？ • 何が • どういう状況下で

振る舞いって何よ？ • 何が • どういう状況下で • どうなるのか

振る舞いって何よ？ • 何が • どういう状況下で • どうなるのかこれらを先に書いていくのが振る舞い駆動開発！

うーん、よくわからん

普通のテストと何がどう違うの？

よろしいならば戦争実際のコードを見てみよう

要件麻雀の牌姿を文字列で受け取り点数を返す関数

従来のテスト (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) }) } }

これはこれでいい、だがしかし • テストケースの条件が増えた時、条件と実際の呼び出し部分とに大きな距離が開いてしまう • いったいなんのテストを書いているのか分からなくなる • テストケースの構造体以上の表現力を持てない • テストケースの書き方に制限はなく、それぞれが書きたいように書いてしま
う

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

テスト対象が俯瞰しやすくなる！ • Describe: テスト対象 • Context: 条件の違い • It: 期待する動作
これらの単語を用いて表現していくので、テスト対象や、その条件などを把握しやすくなる

つまり呼び方や、書き方を変えただけ？

その通り！

but 「その、書き方が重要なんだ」という強い意思が RSpecやGinkgoを作った

「テストを書く」「スペック(仕様)を書く」

BDDの世界へようこそ

ありがとうございました [参考文献] スはスペックのス https://magazine.rubyist.net/articles/0021/0021-Rspec.html

ギはGinkgoのギ

ギはGinkgoのギ

木内智史之介

More Decks by 木内智史之介

Other Decks in Programming

Featured

Transcript