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