Category Archives: software test

QuickCheck on RSpec

CIで何回も回すから味の出てくるテストケースを考えてみる にも書いたように、同値に区分されるテストデータの集合に対してテストを実施する場合、ランダムな値でテストデータのバリエーションを増やすことは現実的な選択肢としてありと思う。また、全網羅が難しいテスト対象の領域に対してこのようにランダムな値を適用することは現実的な選択肢になる。 ※ランダム性は議論の範囲外 ここでは、以前から知られているQuickCheckを以下でRubyのコードを使ってためしていく。 また、先日書いた RSpecによるテストコードでパラメタライズドテストを記述していく と少し比較もしてみる。More

RSpecによるテストコードでパラメタライズドテストを記述していく

以前、FitNesseなどによるSpecification By Exampleで少し示した keyword driven testingは、入力値とその操作まで変数としてテストコードに与えることができていました。 このような形式で記述するテストは、「テストしたい対象のメソッドの入力とその期待値が異なる組み合わでいくつも存在するが、それらのテストを可読性の高い状態、簡潔な表現で保ちたい」というような場合に使えます。実際、開発速度が速い場合、仕様書を別ドキュメントとして厚く保つことは難しいと思います。その対策として、可読性の高いテストで低レベル（メソッドの入出力レベル）のテストはテストを仕様書に見立てていく、というアプローチが重要な一手となります。 以下は、パラメタライズドテストと呼ばれます。rspec-parameterized’というgemを使ってます。More

FitNesseなどによるSpecification By Example

はじめに LEANやAgile、BDDやATDDなどとあわせて、Specification by Exampleという、包括的な考え方が広まってきました。 これは、例によって振る舞い（仕様）を定めていく、という形のアプローチになりますが、そのときによく使われるツールが着想として面白い。 仕様としての例をWikiにより管理し、実装対象の例えばAPIに対してインプット、アウトプットを定義する。そしてそれを受け入れ試験の1つとして活用する。 これは、自然言語で例を与えながら仕様を明確にしていくことと、Wiki形式で表現することで理解しやすい形式にすること、開発物のインタフェースの検証のテストとして受け入れテストのインプット・アウトプットの検証にそのままWikiの記述が使われるところが有用です。More

アジャイルソフトウェア要求を読んで_rev2

以前の5章までの続きです。 ポイント 受け入れてスティングの自動化はチームの開発速度低下を抑制する。 受け入れ基準を大事にするUser Storyの開発スタイルは、よりリーンな考え方を組み込んでおり、生産スピードを向上させる。 より良いストーリーと、それに対する受け入れ基準・テストを用意できることが重要   第6章のユーザストーリーから。。。  More

Turnip+Appiumで使ってキーワード駆動のシナリオテストが実施できそうね

Genymotionの制御用引数がAppiumにプルリクされている所をみて、AppiumのOSSとしての成長加速時期がき始めているのかなと感じる最近です。Appium 0.17.3の次のリリースで含まれるのでしょうか。Androidの検証基盤としても本格的な立ち位置になりそう。 今日はStory Testでお世話になるであろうData / Keyword Driven Testingを少しおさらい。More

Reading Best practice of story test

最近、Story Testの形に関して考えています。 目的は、AgileやLEANにて検証の対象となるStory/User Storyに対する評価としてStory Testをベースにしていきたい、というためです。 なぜなら、検証したい対象の形式に沿って、自動化するなりするときに”検証すべき興味の対象”と表現をあわせて試験を実施するほうが、価値に対する妥当性の議論の火種になったりという副産物を得ることができる可能性があるためとなります。 いくつかざっと目を通したのですが、ひとまずの参考と考え方を整理するために以下を参考にしました。 1. http://www.infoq.com/jp/news/2011/05/representing-agile-testing 2-1. http://www.scrumcrazy.com/Basic+Story+Testing+Styles 2-2. http://www.scrumcrazy.com/Basic+Story+Testing+Styles+-+Part+2 以下のExampleは、いずれも参考先を引用させてもらってます。More

アジャイルソフトウェア要求を5章まで読んで

Explore it! を読んでいたのですが、勤先での立ち振る舞いから、こちらの情報を早くインプットしたくなったので・・・ アジャイル要求を5章まで読んで。 書かれていたのは、ソフトウェア開発プロセスの歴史のお話しと、LENAなAgile開発での中核となる成果物、User Storyからその達成までの全体像でした。 以下は私の理解の要所要所を。詳しくは本書をお読みください。 ※過去に紙の本買ってたのですが、携帯性からついついKindle本にも手が出てしまった・・・More

“Turnip or RSpec” x Appium

過去、こちらにて、AppiumにおけるテストシナリオをTurnipとRSpecのそれぞれの記述で比較してみました。 当時からまたいろいろ試し、考えてみた結果、ひとまずこうかな、という結論に達したのでメモがてら。More

CIで何回も回すから味の出てくるテストケースを考えてみる

テストの価値の話し。 前提として、銀の弾丸のように様々なシチュエーションに耐える話しではないことは断っておきます。 ソフトウェアテストを知っている人の場合、ランダムな値をテストのインプットとすることは良くないと考える方が多いと思います。一方で、最近ではコミットごとにCIをぐるぐる回すような開発環境も日常化してきました。その、CIをコミットごとにぐるぐる回す環境を活かし、ランダムな値をテストに取り入れ、より効率的なテストができないかとここ数ヶ月思っています。 結論から言えば、同値に区分される入力値に関して、1つのテストケースにおいてCIをまわすごとに異なる値を入力とする機構を仕込むことで、CIをまわせばまわすだけ、1つのテストケースでまわしただけの組み合わせにて入力値の確認ができる、という形です。 ここで、同値に区分されるべき値の中からランダムに要素を選ぶので、試験を失敗するということは実装を誤っているか、テスト（想定する振る舞い）を誤っているかのどちらかといえる可能性があり、それに気づくことができます。More