ソフトウェアのテストはたいへんだなあ ソフトウェアのテスト、きちんとしてますか？最近は、スマートフォンやタブレットの普及に伴って、ユーザが使うデバイスの種類が多様化しています。 使われるOSやブラウザ、画面サイズの種類が増える中、プリキュア1の多様化も著しいですね。「プリキュアで学ぶワンライナーWebスクレイピング」で検証した通り、昨年までは43人、今年は「魔法つかいプリキュア」が加わることで、プリキュアの数は総勢45人になりました2。プリキュアはキャラクターによって専用デバイスを持ったり3、感情が昂ぶると常識を覆す事象を起こしたりするので、ITサービスを提供するエンジニアの方々は、ユーザ満足度向上のため、当然プリキュアがユーザになった場合も考慮した動作テストをされていると思います。 とはいえ、プラットフォームとプリキュアの組み合わせの数は、既にかなりの数です。全てのパターンを試すととても
どうも、テストを書きたくない人という認識がされているのだけど、ぼくが書きたくないのは退屈で割にあわないテストで、品質が求められる部分のテストを書くのは、楽しいし、かなり好きです。 それは、たとえば品質について理解してないお客さんのプロダクトだとしても、やっぱり間違ってちゃいけない部分は、せかされても待たせて時間とってテスト書くわけです。金額計算とか。 そのかわり、商品一覧に削除済み商品がでちゃったとか、そういうところは見つかったら直せばいいかーとかで、機能見せれる早さ優先でやったりするわけです。品質対策にかかるコストのほとんどはバグの発見のためのコストで、見つかったバグを直すのは時間かからないし。そもそもそういうのは「言ってなかったけどそこは対応するメーカーがない商品も削除扱いだから」みたいなことをあとから言われることが多いわけで。 でも、まあ、結局１年間は見つかったバグを直しますよってい
Step Back and Automate, Automate, AutomateCay Horstmann面倒でも自動化できることは自動化するケイ・ホルストマンどういうこと？最初は面倒でも、自動化できる部分は積極的に自動化しなければなりません。自動化できそうな作業があっても、わざわざ何度も同じ手作業を繰り返す人は少なくありません。それは、以下のような「誤解」のせいです。【誤解１】自動化はテストだけのもの【誤解２】IDEを使っていれば自動化の必要はない【誤解３】自動化のためには特殊なツールについて学ぶ必要がある【誤解４】扱うファイルの形式によっては自動化ができないこともある【誤解５】忙しくて自動化のことまで勉強している時間はないどうして？自動化すれば、ただ面倒な作業から解放されるだけでなく、作業時間が短縮され、正確さも増します。どうすれば？【誤解１】自動化はテストだけのものテストだけと決
昨日のソフトバンクの非公式JavaScript対応の調査結果 | 徳丸浩の日記で報告したように、昨年5月に、ソフトバンク60機種の検証を行い、JavaScript対応の状況などを調査しました。当時はまだ公式なJavaScript対応機種はない状態でしたが、既にほとんどの端末が *非公式に* JavaScriptに対応していました。 このエントリでは、検証の様子を報告します。 なぜJavaScript対応状況を調査したか http://www.hash-c.co.jp/info/20091124.htmlを公表した前後に、とある方（この方）から、ソフトバンクのケータイでもJavaScriptが動作すると伺いました（参考のやりとり）。XMLHttpRequestも含めてJavaScrptが動くと教えていただいた932SHを私も購入して調べたところ、以下が判明しました。 確かにJavaScrip
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
今まで、パフォーマンスに注意しなきゃいけないところは テストに StopWatch stopWatch = new StopWatch(); List<Long> times = new ArrayList<Long>(); for(int i = 0 ; i < 100 ; i++){ stopWatch.reset(); stopWatch.start(); foo.bar(); //計測する処理 stopWatch.stop(); times.add(stopWatch.getTime()); } BigDecimal sum = new BigDecimal(0L); for(Long i : times){ sum = sum.add(new BigDecimal(i)); } Long average = sum.divide(new BigDecimal(times.size
テストの網羅性については様々なものがある。基本的な網羅性の観点としては、構造ベース、仕様ベース、外部の標準や指標ベースなどが挙げられる。 そして観点ごとに、様々な網羅性の指標がある。ユニットテストの場合だと、例えば以下がある。 コードの構造網羅 コードの構造を網羅する。ここでいうコードの構造としては、制御フロー、データーフロー、例外フローなどがある。具体的な指標としては、コードカバレッジが有名。コードの構造網羅では、コードカバレッジなどを基準にして、基準以上の網羅性を確保できるようにテストを設計する。 なお、構造網羅というと、一般的な定義ではコード以外の構造も扱われるが、このブログでは便宜上「構造網羅をコードの構造を網羅すること」という定義に絞り込んで説明する。 仕様網羅 コードの仕様を網羅する。コードの仕様には、対象（対象の粒度はテストレベルに依存する。例えば関数やクラス、モジュールを単
とある案件が終わった。相変わらずきっつい納期だったうえに、全メンバー片手間の情況でよくやれたなと自画自賛していいと思う。 ふりかえりをツイートしたら清水川大明神先生様に「それブログで」って言われたので、すこし整理してみた。 テスト テストを書く習慣が付いたのはつい数ヶ月前のことなのだが、この案件ではテストが非常に役立った。 もともとFlashゲームのバックエンドAPIサーバーを作る仕事だったのでサーバー側のテストがしやすいというのもあったが、初期からテストのしやすさを意識して書いた。 マイルストーン期日が押していても１機能に対して最低ひとつ、想定通りの値で想定通りの結果が返ることを確認するテストを書いた。 それだけでも下らないバグは十分に防げた。 目標設定 テストの数が50を越えた頃から、100テストを目標にしていた。 カバレッジとかは一切計算していないし、100という数字にも何の根拠もな
グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか？ グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl
xUnit Test Patterns: Refactoring Test Code 良さを伝えるのは結構難しい。勉強会も開かれているので広く読まれている事は間違いない。ただ読むのはしんどい。「どこから読み始めても分かるように」という筆者のありがたい配慮により、とにかく冗長な構成。全く同じ文章をコピペしたのではないか？という箇所もちらほら。おかげで833ページ。 読む価値はある。筆者は間違いなくテストを書く事と真剣に向き合っている。本書でしか読めないパターンも多い。Mock Object、Stub、Test Spy の違い。Slow Test に立ち向かうための Fixture 。種々の Result Verification 手法などお腹いっぱいの内容。 本書が出たのは 2007年5月。やっと 2007年のテスト事情まで追いついた。次は2009年末に出たGrowing Object-Or
テストを書いているとモックオブジェクトを使う機会が多いと思います。そのモックオブジェクトは自前で作るよりは、JMockやMockito*1などのフレームワークを利用した方が楽でしょう。 今回は機能的に、ほぼ最強と思われるJMockitを紹介します。 これが、他のモックフレームワークとの機能比較です。 MockingToolkitComparisonMatrix - jmockit - A feature matrix comparing several mocking toolkits. - Project Hosting on Google Code 機能が多ければ使いやすいか。そんなことはないと思います。しかし、これは使いやすいかもと周りの人からお勧めがあったので、実際に使ってどんなところが使えるのか検証してみたので、書いてみます。あと、最後にScalaで使えるか試してみました。 あ、
結論を最初に書くと、 テストコードを書くだけではダメで、デイリービルドなりCIしないと意味ないんじゃないっすか？という事です。 最近Hudsonを使っていてすごいいいなぁ、と思うのがこの画面。 「リグレッション」という表現はすごい的を射ているなぁ、と思います。以前は「失敗」となっていたと記憶しています。 なんで的を射ているかと思ったかと言うと、テストコードって回帰テストの中で動かされると、その結果は「成功」と「失敗」だけではありませんよね。仕様変更による影響がテストコードので、テストコードが失敗すると言う事もある訳で。確かid:hyoshiokさんのブログだったかで拝見したかなんかだったんですが、Oracleでは毎朝デベロッパが出社すると、QA担当の人から失敗した回帰テストが回覧し、デベロッパに「これは障害なのか、仕様変更による影響なのか」を判断してもらった、と言う話を目にしました。テスト
Rules とは JUnit4.7から@Ruleアノテーションが追加されました。@Ruleアノテーションは、org.junit.rules.MethodRuleインターフェースのサブクラスによって定義された振る舞いをテストメソッドに追加します。 MethodRuleの組み込み実装クラス MethodRuleの具象クラスとして、以下のクラスが提供されています。 MethodRule ├ Verifier : オブジェクトの状態が不正な場合にテストを失敗させる │ └ ErrorCollector : 1つのテストメソッドの複数のエラーを集集する ├ ExpectedException : スローされた例外について柔軟なアサーションを行う ├ ExternalResource : サーバの起動停止などの外部リソースの操作を行う │ └ TemporaryFolder: テストメソッド前に一時フ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く