test – Page 14 – ~ my tech diary ~

Agile Samurai Base Camp 2014 Re:TDDに参加した

Agile Samurai Base Camp 2014 Re:TDD に参加してみた。このイベントは、アジャイルサムライを読んだ人が、入門的に実際に手を動かそうとしているところ。目的テストエンジニアも、具体的な側面として少なからずTDDなり実践することができるべきだと思ったテスト技法を用いたテストコードの改善に立ち向かうには、書いて実践することがやはりテストエンジニアには求められると感じたそのため、まずはTDDの基本を学ぼう、と思った。まとめ TDDはやはり開発者を支援するための道具としてのテスト TDDはコード（サービス）、チームを健康体にするための開発スタイル仲間、大事。社内外で友達を見つけることは大事。 programmingを楽しく継続させるために、無理せず健康的にがんばろうその他テスト駆動開発入門が絶版になっているらしい。私は既に買っていてよかった。 jasmine, groovy & spock のテストをみて、Spec系の記述が主流かなと思った。というか、groovy & spockの不具合発生時のエラー表示は強力だなと思った。レガシーコードはif文、for文から、独立性の比較的高いところをmethodにして書き出して、小さいところから実施していく。弊社のような事例はやはり希有なので、いろいろ考えないとなと感じた。。。More

Explore it !を少し読んでみた。第一章。

探索的テストを学ぼうということで、Explore it ! を読んでみた。 Explore it ! まだ途中ですが、メモがてら。この本は、主にはTester/Testengineerを対象とするが、この探索的テストはモデリングなどのソフトウェア開発の領域の知識も必要とする。そのため、テストを書くプログラマなどに対しても有効な情報のインプットとなる。このExplore it!では、以下のような構成で話を進めている。 Establishing Foundations Adding Dimensions Putting It in ContextMore

アジャイルソフトウェア要求vol4最後

Agile手法に対するアーキテクチャーは、個々のチームから複数のチームへとAgile手法の拡大を進めていくと必要になっていく。一方で、AgileやLEANを失わずに進めていくことが課題。基本的な原則More

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

13章以降の、第三部に属する箇所に関していくつか記載。 13章従来のソフトウェア開発では、Product Requirement DocumentやSoftware Requirement Documentなどの要求仕様書を用意し、開発を行っていた。これらのドキュメントは重く、リーンな開発では特に、小さく始める、Just In Time、動くものをより素早くというところがあり従来のように重たいドキュメントは歓迎されない。また、リーンソフトウェア開発の原則にある「決定を送らせる」ことを実現するには、やはり従来のように重たいドキュメントは歓迎されない。一方、AgileやLEANではビジョンを伝え、共有することが必須である。そのため、それらの共有に力を入れる。これは以下のような問いに対する回答であり、一般的に5〜10ページ程度の文章となる。このシステムはなぜ構築しているのか？これがどのような問題を解決するか？どのフィーチャーと恩恵（価値）を提供するか？誰に対してフィーチャーと恩恵（価値）を提供するか？どのような性能/信頼性/スケーラビリティで提供しないといけないか？プラットフォームなどのサポートは？ひな形は本書の付録にあるので、そちらを参考に。More

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

Tag Archives: test