テストコードのあり方

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

【「DTで連想するものは？」であなたが何クラスタか判定する】 DT = デシジョンテーブル -> 品質系 DT = 田園都市線 -> 渋谷使う系 DT = Defencive Tackle -> アメフト系 DT = Dream Theater -> メタル系

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

とりあえずDreamTheaterは聞くといい。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@t_wada お手透きな時に返事をもらえると幸いです。結合テスト(WebであればHTTPを介して、ライブラリであれば公開されているAPIでのユースケース)のテストで、1テストクラスにどれくらいのテストメソッド(検査したい項目。assertの数ではない)を書きますか？

Takuto Wada @t_wada

@kyon_mm クラスの中にいくつ書くかは設計やフレームワークによって変わるので状況によります。結合テストの場合には細かすぎるといろいろ大変なので、検査したい項目をユーザの操作でまとめられる単位のテストシナリオにして、主に機能に対してクラス、シナリオに対してメソッドで書いてます

Takuto Wada @t_wada

@kyon_mm DT = 童貞 -> 伊集院クラスタ

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@t_wada なるほど。その機能と言っているものの出力（つまり、各シナリオでの最終的な結果）はほとんど同じということでいいですか？もちろん、途中でチェックする項目はあると思いますが。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@t_wada まさかの伊集院クラスタ！ｗ

Takuto Wada @t_wada

@kyon_mm きょんくんの最初の質問にあった結合テストってどんなものでしょう? 私は Web アプリに対してたとえば Selenium や Casper.js などを使って画面遷移を伴うテストかなと思って答えました。そういう文脈では、最終的な結果はシナリオによってバラバラです

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@t_wada 直面しているのはライブラリなのですが、Seleniumでも僕は同じように捉えると考えています。先のは「会員登録機能というテストクラスをつくって、A->B->C->登録完了と遷移するテストメソッド、A->D->E->登録完了と遷移するテストメソッド」だと思いました。

Takuto Wada @t_wada

@kyon_mm きょんくんの理解で合ってます。「会員登録機能というテストクラスをつくって、A->B->C->登録完了と遷移するテストメソッド、A->D->E->登録完了と遷移するテストメソッド」のようにメソッドを作っていきます。そのメソッドの各所に assert を書きます。

Takuto Wada @t_wada

@kyon_mm これから夕会に参加するので、ちょっと反応悪くなります

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@t_wada そのときに「登録成功」「登録失敗」以外のテストメソッドって書きますか？つまり、別の機能を使って、別の結果を得られるようなテストメソッドです。「○○をしているときにも会員登録ができる」などの直交性のテストは「登録成功」のテストメソッド群の一部として数えます。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@t_wada りょうかいですー。

Takuto Wada @t_wada

@kyon_mm 私の場合は、書かないと思います。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@t_wada なるほど。仮にですが、そのシナリオ(遷移の方法、各状態でチェックする内容)をパラメタライズできるのであれば、1つのテストクラスには1つのテストメソッドしか書かないことになると思うのですがどうでしょう。僕は正にそういった考えを抱いていて、この質問をはじめました。

Takuto Wada @t_wada

@kyon_mm それは「登録成功」「登録失敗」までパラメータにするということですか? 全てパラメタライズすればそうかも。各シナリオが基本的に似ていて、ちょっとずつ違うような場合にはパラメタライズが有効に働きそうです。各シナリオが大幅に異なる場合には……どうなるか見てみたいですね

Takuto Wada @t_wada

@kyon_mm 私の回答きょんくんの役に立っているかな? 私はあまり大したことを言っていない気がします。役立つなら良いのだけど……

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@t_wada 結果(出力)毎に別になるイメージです。異常系の扱いは今試行錯誤中で一緒にするか悩んでいますが、今は別にしています。「A機能がもたらす結果毎にクラスをつくる」というイメージです。今は、異常系や網羅基準の変更は基本となるテストクラスの拡張で表現しています。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@t_wada いえ、とても役に立っています。社内ではbleisさんには相談したのですが、誰に聞いていいかわからず＞＜

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

いまやっているテストクラスの抽象化がすごく楽しいんだけど聞かない話なだけにすごい慎重になっているということ。

Takuto Wada @t_wada

@kyon_mm その方針はアリだと思います。私はこれまで「一つの事前条件から様々な遷移によって様々な結果になる」のは Testcase class per Fixture にして、「様々な事前条件から同じような結果になる」場合には我流でした。きょんくんのアプローチは面白そう。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@t_wada ありがとうございます。いま考えているのはあらゆるテストは組み合わせを自動化したほうがいいと思ったことです。なのでSpockは僕の中ではもう終わっていて、関心は「因子」「水準」「制約」であり、因子が操作であってもそれは一緒でそれのみをどうやって書くかということでした

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@t_wada なので、入力、設定、また操作手順も因子、水準、制約、依存関係で表現していて、自動で組み合わせるようにテストコードをシフトしています。Assertの抽象化とかもあるのですが、それは今回とは別です。面白いのはこうしたテストクラスはテスト観点と1対1になったことでした。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

僕の中でテストコードが劇的に進化したのでこの2週間は素晴らしい。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

まだいくつか乗り越える壁はあるけど、いいですね。はい。