テスト自動化研究会 - テスト自動化の8原則
1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。 解説 1. 手動テストはなくならない ユーザビリティテ
「レガシーコード改善ガイド」のススメ 第1回：レガシーコードの定義、テストの重要性とは
「レガシーコード」とは何か 最初に1つ質問です。皆さんは、「レガシーコード」と聞いて何を想像するでしょうか？ 多くの方はCOBOLなどで書かれたメインフレームで動くコードを真っ先に思い浮かべるのではないかと思います。しかし、本当にそれだけでしょうか？ ここでは「レガシーコード」という言葉を『何年も前に誰かが作り、内容が複雑で何をしているのかよく分からず、まともな仕様書もない』というコードを指すものとします。そう考えると、必ずしもメインフレームだけの話ではなくなります。この記事を読んでいる皆さんなら、そのようなコードを少なからず目にしていることでしょう。 現在の業務システムは、Java EEや.NETなどの基盤上に構築される、いわゆるオープンシステムが主流になっています。このようなオープンシステムであっても、構築されてから既に5年以上経過していることが珍しくなく、何度も手が加えられたコードは
効果の高いテストについて考える - gong023の日記
テストエンジニアという奇異な立場にいる。 普通にプロダクトメンバーの一員だが、プロダクト自体のコードはあまり書かず、品質という観点から良かれと思ったことをする。大体グーグルのテスト本に載っているSETをロールモデルとしている。 テストから見えてくる グーグルのソフトウェア開発 作者: ジェームズ・ウィテカー,ジェーソン・アーボン,ジェフ・キャローロ,長尾高弘出版社/メーカー: 日経BP社発売日: 2013/05/23メディア: 単行本この商品を含むブログ (8件) を見る SWTは、例えばエンジニアがテストを書きやすいようにライブラリを作ったり、テストがリリースのネックにならないように高速化したり、手動テストを支援するようなサポートツールを作ったりするのが役割となる。普通に単体テストも書く。（が、それはあまり理想ではなくて、本当はそのコードを書いた人が単体テストも書くべきだ。） しかし、現
FlawedTheoryBehindUnitTesting - 単体テストに潜む誤った理論
FlawedTheoryBehindUnitTesting - 単体テストに潜む誤った理論 目次 この文書について 単体テストに潜む誤った理論 単体テストに潜む誤った理論 この文書について "The Flawed Theory Behind Unit Testing" の日本語訳です http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... 私は Google の blogsearch 一式を使って単体テストに関する話題を拾っている。 普段は一週間に数十の blog やメーリングリストの議論に目を通す。 新しい話題もたまにはある。けれど、多くの話題は繰り返しだ。同じ主張が何度も現れる。 その中でもひときわ私を悩ませる
テストを書く - シンデレラは削らない
http://t-wada.hatenablog.jp/entry/debugging-tests 和田さーん！ テスト駆動開発（TDD : Test Driven Development）は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか？ やはりテストを書いて立ち向かってゆくのです。 チーム内にテストを書く習慣を持ち込んで三年、最初のうちは工数が増えるだけだ（あるある）、テストを書いても不具合がでるじゃないか（あるある）、システムテストでカバーすればいい（あるある）などという抵抗があり、それでも僕は淡々と雨の日も、晴れの日も、雪の日も、朝も夜も深夜も、終電後のオフィスでも、GW中の人気のないオフィスでも、自動テスト
いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ
色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。 あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。 そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル
【翻訳】TDD is Fun - diskogs's diary
@solnicが、DHHの例の記事へのカウンター的な記事をポストしてまして、自分のために読んでみたらよい内容だと思ったので、翻訳してみました。翻訳ミスとかあると思いますが、、、すみませんです。。。 TDD is Fun Posted by solnic on Apr 23 2014 著 solnic 2014年4月23日 Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
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
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編） 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡山五郎氏の講演「自動改札機ソフトウェアの品質向上の取り組み 厳密な仕様、もらさないテストを目指して」。この記事では、そのダイジェストを紹介しています。 本記事は、前編、中編、後編の3部構成です。お読みのページは後編です。 大規模なテストをどうやって実行しているか 続いて、大規模なテストについて。 1000万件のテストパターンを作っても、それぞれのテスト結果の正解を人手で作っていたら追いつきません。なので、別々に運賃計算ソフトウェアを作って、その答えを突き合わせてチェックしよう、という話です。 例
BDDについて自分なりにまとめてみた - ukstudio
BDDという言葉も割と人によって指すものが違うようなので「俺の中でのBDDはこうだよ」って内容のエントリ。別に絶対的なものでもないと思うので参考までに 結論から とりあえず結論だけ知りたい人向けに。 BDDにはふたつの種類がある TDDの言い換えのBDD(開発寄り) ATDD(受け入れテスト)でのBDD(ユーザ寄り) 振る舞い BDDは振る舞い駆動開発と言われたりするように、テストという言葉のかわりに振る舞いという言葉を使う。日本語的には仕様と言うほうがわかりやすいかもしれない。多分、BDDのイメージが掴みにくいのはこの振る舞いという言葉にあると思う。と言うのも振る舞いと言うのは、人の立場よって変わるからだ。例えば、プログラマがあるクラスを実装している時に言う振る舞いはそのクラスのメソッドとかの仕様になる。逆にユーザレベルの人が言う振る舞いはアプリケーションの要件・動作を言うだろう。 つま
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
privateメソッドのテストについて
瀬良 @shela_ @irof publicからprivateを含めて検証するのと、private単体だけで検証するのであれば、先にprivate単体で検証しておいた方が安心感があると思う 2012-08-25 16:38:24
状態のあるコードに対するテストの自動生成 - 西尾泰和のはてなダイアリー
BLUE*アルゴリズムを実装してみたので、せっかくだからテストの自動生成をやってみた。 今回テスト対象にするコードの仕様は 開く、閉じる、書き込む、の3つの操作ができる 開いてないのに書き込んだり閉じたりしたらエラーになる というもの そしてこちらがそれの「バグのある実装」： class Target(object): # bad impl. def __init__(self): self.opened = False self.closed = False def open(self): self.opened = True def write(self): if not self.opened: raise RuntimeError if self.closed: raise RuntimeError def close(self): if not self.opened: rais
レガシーコード改善ガイド : 小野和俊のブログ
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
新人注目！ テストを極める最初の一歩 記事一覧 | gihyo.jp
第3回コピー＆ペーストでテスト仕様書を作っていませんか？ 鈴木三紀夫，池田暁 2008-07-14
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bitbucket | Git solution for teams using Jira