編集・発行元 独立行政法人情報処理推進機構（IPA） 技術本部 ソフトウェア高信頼化センター（SEC） 発行日 2015年5月29日 サイズ A5判 ページ数 216ページ 定価 1,019円（税込） ITやそれを活用したビジネスの領域は、様々な製品やサービスが複雑に連携しながら「つながる」システムを構成し、全体として利用者に新たな価値を提供する世界に確実にシフトしています。このような価値を利用者に届けるために、また利用者に対する品質に関する説明責任を果たすために、事業者にはこれまで以上に品質に対する広範囲な理解と包括的な取組みが求められます。 本ガイドブックは、このような背景のもとで、製品・サービスを提供する事業者が、広い視点で品質要求を洗い出し、確実に設計・実装し、かつ定量的に評価するための指針を規定した国際規格「SQuaRE」(注釈1)について、上記の背景とそこで必要となる品質の考え
ソフトウェアの自動テストで使う代品オブジェクト――いわゆる「 テストダブル 」の種類についてまとめました。 タイトルには「スタブ」「スパイ」「モック」の 3 つだけをあげていますが、他にも「フェイクオブジェクト」と「ダミーオブジェクト」に言及しています。 お断り この記事の説明は書籍『 xUnit Test Patterns: Refactoring Test Code 』（ Gerard Meszaros 著）の定義に基づいています。 このあたりの用語の定義は人や流派によって異なります。この記事の説明が常に正しいわけではありません。 テストダブルの全体像 テストダブルの分類は次のようになっています。 テストスタブ・テストスパイ・モックオブジェクト等のテスト用の道具をまとめてテストダブルと呼びます。 テストダブルとはプログラムの中でオブジェクトや関数やモジュール（以下これらをまとめて「コン
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。 解説 1. 手動テストはなくならない ユーザビリティテ
テスト仕様を書くだけで，仕様書自身がテストを自動でやってくれる。 それがExcelenium（エクセレニウム）。 Excelenium ＝ Excel ＋ Selenium 左側で，操作のステップを日本語で書くと， 右側で，テスト仕様書風のフォーマットの文章をリアルタイムで自動生成してくれる。 ※画像中で「確認」と書いてあるのは，チェックポイントの部分。これは自動的にオレンジ色のセルになる。 書く必要があるのは，青い線より左側だけ。 そして， 「この仕様書の全テストを実行」 というボタンを押すと・・・ Seleniumのテストケースが自動生成され， ブラウザが立ち上がり， テスト仕様書に書いてあった全テストが実行される。 （※ついでに，シート上の全テストケースに自動で番号が振られる。） Webアプリケーションの結合テスト / 回帰テストが大幅に楽になる。 従来のような「テスト仕様書」と称し
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
AWSのリソース構成をServerspecのようにテストできる "awspec" をつくりました。 github.com 例えばEC2インスタンスであれば、以下のように書けます。 describe ec2('my-ec2') do it { should exist } it { should be_running } it { should_not be_stopped } its(:instance_id) { should eq 'i-ec12345a' } its(:private_ip_address) { should eq '10.0.1.1' } it { should have_security_group('my-security-group-name') } it { should belong_to_vpc('my-vpc') } it { should belon
https://atnd.org/events/66159 で実施したプレゼン資料
テストドリブンしてますか？私は勿論してません。え……。別に赤が緑になっても嬉しくないし。コード先でテスト後のほうが書きやすくていいなあ。でもそうなると、テスト書かなくなってしまって、溜まるともっと書かなくなってしまっての悪循環。 そんな普段あまりテスト書かないクソッタレな人間なわけですが(レガシーコード殺害ガイドが泣いている)、普段テスト書かないだけに書こうとすると単純なものですらイライライライラしてしまって大変よくない。しかし、それはそもそもテストツールが悪いんじゃね？という気だってする。言い訳じゃなく、ふつーにバッチイですよ、テストコード。こんなの書くのはそりゃ苦痛ってものです。 Before 例えば、こういうどうでもいいクラスがあったとします。 public class MyClass { public string GetString(string unya) { return (
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
