このエントリーは、@cero-tさんのエントリーの次で、Java Advent Calendar 2011の6番目のエントリーです。自分自身の今年のメインテーマがTDD（テスト駆動開発）と言う事もあり、関連エントリーとしてJUnitについて書きたいかと思います。今更JUnit？と思われた方も普段からJUnitを使っていあなたも気軽にお読みください。尚、色々な話題を駆け足で紹介するので、どれも簡単な紹介程度になってしまいますが、ご了承願います。 JUnit4 スタイル JUnitがアノテーションに対応し結構な月日が流れましたが、古いコーディング規約のままでテストコードを書いていませんか？JUnit4では、アノテーションとアサーションを使ったテストコードを書くことが基本スタイルです。かつては、TestCaseのサブクラスを作り、testではじまるメソッドを定義していましたが、今は Testアノ
jQuery や Backbone.js で UI を開発していて面倒なのが、サーバー側の API を呼び出す部分の実装です。呼び出したい API が既に実装されていないと、細かいところまで作り込めません。 あと、上手く動かなかったときも面倒です。原因がクライアント側ならすぐ直せますが、サーバー側だった場合、サーバー側のコードを修正して、テストまでしないといけません。効率悪いですよね。 できれば、クライアント側の開発はクライアント側だけで完結したい。さらに欲を言えば、最終的にサーバー側の API を呼び出すように修正するとき、出来るだけ少ない修正で済むようにしたい。 API 呼び出しを抽象化してダミーの処理と差し替えたり、jQuery.ajax を上書きしたり、色々工夫して最後に行き着いたのが『jquery-mockjax』。 appendto/jquery-mockjax · GitHu
Seleniumを使ったWeb UIの自動テストシステムを作ったので、やったこと・感想などをまとめてみます。 テスト対象 テスト対象は、AJAXなWebアプリです。 サーバーはREST APIを提供するのみで、UIは全てJavaScriptという構成。 サポートブラウザはIE7以降,Firefox3.6以降。(特定の組織内で使うものなので、Operaなどは未サポートです。) 使用したSelenium 2.x 系列を使いました。 WebDriverと統合されたあとのやつです。 言語はJavaを使用。 テストの目的 以下を目的としました。 機能追加/不具合改修でのデグレード防止 機能追加や不具合改修に伴う動作不正を検出し、デグレードを未然に防止する。 動作確認コストの削減による開発効率の向上 ブラウザごとの動作確認を自動テストを利用して行うことで、機能実装時の確認工数を減らす。 リリース前のリ
設計ツールとしてのモックの使い方について考える。 導入 先日、"Mock Roles, not Objects"の日本語版「ロールをモックせよ」を公開しました。この論文は2004年に書かれたもので、著者はSteve Freeman氏、Nat Pryce氏、Tim Mackinnon氏、Joe Walnes氏という豪華メンバーです。また、Steve Freeman氏とNat Pryce氏は『Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))』（いわゆるGOOS）の著者でもあり、"Mock Roles, not Object"で語られている思想はGOOSのベースになっているとも言えます。 今回は、この"Mock Roles, not Objects"（以下、MRnO
テスト駆動開発入門ネクストステップ 1. テスト駆動開発入門 ネクストステップ 井芹洋輝 TDD Boot Camp 東京 for C++ 2011/10/8 @国立情報学研究所 2. 謝辞 • 主催の今給黎さん • 和田さん、会場提供、スタッフの方々 • 参加者の皆さま 深くお礼申しあげます 3. 自己紹介 • 井芹 洋輝(@goyoki/id:goyoki) • 組み込みエンジニア • WACATE実行委員/TDD研究会 • 講演/執筆： – XP祭り関西「ユニットテストの保守性を作りこむ」 – Androidテスト祭り「テストの活用による開発効率化」 – 並カン「FPGA/HDLを活用したソフトウェア並列処理の構築」等 4. 概要 本講義はTDDの基本サイクルを学んだ方 が対象です。 本講義ではTDDを開発で実践するための 知識、TDDについて自立して学習を進め るための情報を学び、
ロールをモックせよ Mock Roles, not Objects Steve Freeman, Nat Pryce, Tim Mackinnon, Joe Walnes ThoughtWorks UK（著） 和智 右桂 Growth xPartners Inc.（翻訳） Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation
この記事では、Facebook のあいさつ(Poke)機能への返信を題材に、沢山たまるとウザい嬉しいあいさつを自動で返すスクリプトを書くことで、Selenium2.x の使い方、特に Ajax アプリをテストする方法について学べるようにする。 Ajax がからんだWebアプリケーションのエンドツーエンドの最近のテスト手法についてのまとめにもなっていると思う。 最初の3節ぐらいは「Seleniumとは〜」とか「テストってのはさー」とかゴタクをごたごた書いているので、Seleniumの実際のコード見た方がはえぇよ。って言う人はコードが出てくるまで記事を飛ばすと良い。 こんな記事を気合入れて書いて公開した当日に…FacebookのUIが変わって…作ってたスクリプト動かなくなってしまった…orz。俺が何かやったり買うと事件が起きるんや・・「なにか買うとその直後に安くなったり、新機種がでたりするとい
BBQ和尚の同僚の方とは知らずタイトル買いした本ですが、タイトルに偽りなしです。とにかく平易で優しいわりにいちいち実践的で助かってます。最小の努力で結果が出るように配慮されています。 経験ゼロでもできるプログラミング現場の単体テスト 作者: 片桐一宗出版社/メーカー: 翔泳社発売日: 2009/05/29メディア: 単行本（ソフトカバー）購入: 11人 クリック: 564回この商品を含むブログ (26件) を見る この本を買ったきっかけは、とにかくデグレを無くしていい意味で手離れの良いコードを書いて楽がしたい、というもの。その為にはテストツールの使い方よりも、｢どうやってテストコードを書けばある一定の品質が保てるのか｣ということが書いてあるまとまった情報が欲しかった。で、本書をあたりました。 テストコードの書き方がわかっても、テストの内容が不十分であったりテストする単位が均質でなければ意味
TDDしたい、CIしたいと思ってもなかなか導入できない。何でだろう？ PHP製WebアプリケーションでのTDDを学び始めた現時点の気持ちまとめ。 Seleniumを使うような高いレイヤーのテスト どんなテストを書けばいいのかわからない 例えばDBから商品情報取ってページ生成する場合。 商品カテゴリごとに異なる趣きのページを作るのでそれぞれにviewのテストを書いたとする 各ページ内の商品詳細URLにパラメータが追加されることになった URL生成は共通のモデルで行っている 修正は一ヶ所で簡単なもの だったとしてもviewのテストはそうは行かない。 先に用意したテストケースを全部書き直さなきゃならない。 小さな変更にかかるコストが大きくなる 単純に時間がかかるというより めんどくさくなる → どうせやらなくなる という思い。 コントローラーとか中間くらいの層のテスト viewよりは下、ユニット
Using English, write down some stories. Suggest some scenarios to fully illustrate the stories. Split the scenarios into sequences of contexts, events and outcomes. Reuse them to describe and illustrate the different behaviours of your system. Run the stories. If you need some code to make the system behave as it should, write down the behaviour of the code. Run the behaviours. If the code isn’t d
JaSST'11 Niigata は約60名にのぼる方々に参加いただき、盛況のうち終了しました。 ご参加、ご協力いただいた皆様、有難うございました。 基調講演 事例発表１ 事例発表２
単体テストレベルでは、「コードカバレッジ」を意識しながら（基準にしながら）テスト設計やテストケース作成を行う機会が多い。でも、この「コードカバレッジ」って用語がばらばらであったり、どのカバレッジ基準がどういうことを確認するものなのか、どういう不具合を見つけられるのか、見つけられないのか、といったことが自分の中でしっかりまとまっていなかったので、いろいろ調べてまとめようと思います。 2008/03/12更新 サンプルプログラムで解説を追加 サンプルプログラムは、以前例題として作成したテニスのスコアボードについて [例題]テニスのスコアボード ステートメントカバレッジ 命令網羅。テスト対象となるプログラム中のステートメント（命令文）をどれくらい実施したかどうかをあらわす基準。すべてのステートメントを最低1回実施した場合に、ステートメントカバレッジ100%という。もっとも基本的なカバレッジ基準で
Home User documentation Installation Quick start Migration guide Articles FAQ Developper documentation Building JWebUnit How-To contribute How-To release Sourceforge Project page Download Modules Code Generator Core - API Commons Tests HtmlUnit Plugin Webdriver Plugin Project Documentation Project Information About Project Team Mailing Lists Project License Issue Tracking Source Repository Project
この記事は，「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。詳細はこちら。 次に，テスト・レビューの基本を解説しよう。実は，テストとレビューで考えるべきことは，かなり共通している。テストでは，テストを実施する前に，テスト項目をきちんと設計しなくてはならない。レビューでも，レビューを実施する前に，指摘項目をきちんと設計すべきである。行き当たりばったりのテストやレビューをしている限り，少ない手間で危険なバグを早くたくさん検出できるようにはならないし，テストやレビューの改善にもつながらない。 テストのやり方にはいくつかの工夫がある（図4）。まず，なるべく網羅性を落とさずに手間を減らし，たくさんバグを検出する方法がある。直交配列表を用いる方法や，All-pair法などが知られている。
品質管理で欠かせない基礎知識を紹介しますね。品質改善ではスキルも必要ですから、頑張って習得しましょう！ それほど難しい話ではありませんから安心してください。 標準偏差とは、バラツキをあらわす目安です。例えば、製品の長さを測定した結果、40、50、60、70、80cmだったとします。 新しいサイトへ移行しました。最新記事はこちら → 標準偏差とは バラツキを見るために、個々のデータから平均値60を引きます（偏差）。 40-60=-20 50-60=-10 60-60=0 70-60=10 80-60=20 －－－－－ 計 0 全体的なバラツキを見たいのですが、このまま加えたのでは、ゼロです。そこで、偏差を２乗します。 (40-60)^2=400 (50-60)^2=100 (60-60)^2=0 (70-60)^2=100 (80-60)^2=400 －－－－－ 計 1000 このままでは、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
