Kanazawa.rb meetup #14のミニコーナー「Test ! Test !! Test !!!」に用意した、テスティングフレームワークざっくり話。使うと何が嬉しいのか、だいたいどういう感じの作りなのか、どんな種類のものがあるのかをだだっと並べてみました。
テスティングフレームワークざっくり@wtnabeKanazawa.rb meetup #142013-10-19 (Sat) at DMM.com Labo Kanazawa
View Slide
お品書きテストコードによるテスト基本的な構成その他の構成要素記述形式や考え⽅
前提とりあえずユニットテストで⾃動化のメリットみたいな話はしませんテストの⾃動化全般の話もしません
テストコードによるテスト
まずは素朴に
/** product */function add(a, b) {return a + b;}/** test */function test_add() {assert_equal(5, add(2, 3));}test_add(); /** run */
登場⼈物productコードtestコードテストの実⾏コード
まさか混ぜておけない
課題どうやって分離する?どうやって実⾏する?どうやって判定する?どうやって集計する?
これらを解決するのがテストハーネス、フレームワークと呼ばれるものです
基本的な構成
とりあえずこんな感じ
xUnitの場合TestCaseテストコードを実際に書くTestSuiteTestCaseのコレクションTestResult結果をまとめるcf. Testing Framework
TestCaseクラスベースOOの場合、TestCaseを継承して普通にclassを書く
その他の構成要素Test Runnerブラウザで, CLIで, IDEで, etcReporter ( Formatter )JUnit.xml, TAP, etcassertions分離しているものもあるTest Double
⼀部端折って全体の様⼦はこんな感じ
周辺プロダクトStagehand_TestRunner (PHP), Karma(JavaScript)shoulda (Ruby), should.js, expect.jsqunit-tap (JavaScript), rspec-extra-formattersSinon.JS, RR (Ruby), Phake (PHP)
モノによって呼び名は変わるけどだいたいこんな感じ
記述形式や考え⽅
ざっくり分類xUnitBDDPerlのTest::Moreみたいなやつほか
さっきのをxUnitっぽく書いてみる
class Foo {function add() {}}// ----class Foo_Test extends TestCase {function setUp() {}function test_add() {}}
たいして変わらない
xUnitのメリットは書き⽅、考え⽅に違和感が少ないこと
BDDで書いてみる
class Foodef add(a, b)endend# ----describe Foo dobefore { }describe '#add' docontext 'given 2 and 3' doit { }endendend
BDDは語彙が違うexample, specを書くそのための⾔葉を使う素朴な「クラス - メソッド」の書き⽅より柔軟で記述量を減らせる場合も
Test::Moreっぽく
package Foo;sub add {}# ----use Test::More;use Foo;is(5, Foo::add(2, 3)); # <-done_testing;
とにかくシンプル継承とかメソッドに名前が必要ないis, ok などめちゃくちゃ短い語彙も少ない「場合」が増えてくると⼯夫が必要
Q & A
Q. どれ使えばいいの?
A. そのプラットフォームで使ってる⼈が多いやつにしときましょう
おしまい