テストコードのリファクタリングJJUG CCC 2012 fall / 札幌Javaカンファレンス2012での発表資料です。 ソースコードは https://github.com/shuji/demo-refactering-unittest から取得してください。Read less
JavaScriptのテストツール「testem」が素晴らしいぞ - Mach3.laBlog
この記事は賞味期限切れです。（更新から1年が経過しています） JavaScriptユニットテスト一年生の私が、Nettuts+ のチュートリアルで知ったテストツール 「testem」のお陰で大変捗ったので是非お勧めしたく、ここで紹介してみます。 testem ってなに testem via GitHub : airportyh/testem Unit testing in Javascript can be tedious and painful, but Testem makes it so easy that you will actually want to write tests. 要するに、面倒なJSのユニットテストをより快適にしてみんなでハッピーにテスト書こうよ！というツールです。 testem自体はnode.jsベースで動作し、Jasmine/QUnit/Mochaに対応して
クリティカルな障害となるQAやテスト - 千里霧中の犀
先日、実行委員として第二回Androidテスト祭りに参加させて頂きました。今回はレポート係も担当したので後ほどCodezineに報告記事を掲載する予定です。 なお今回改めて実感したのが「QAやテストが、ビジネスにとってクリティカルな障壁となっている」という現状です。その実感は自分のいる医療産業でも感じることですが、Android開発では違った理由からそうなっているのが興味深いと感じています。 Android開発の現状 ちょっと前置きが長くなりますが、まずAndroid開発では開発で取り得る選択肢が多種多様になっています。例えば多種多様なツールやフレームワーク、情報、ライブラリ、サービスなどがあり、それらを組み込むことで色々な機能を実現できます（例えばDropBox APIを使えば共有ストレージ機能を実現できますし、Twitter APIを使えばSNSとの連携も実現されます)。こうなっている
JUnit 強化キャンプに参加してきた #junitbc - Diary of absj31
JUnit 強化キャンプ : ATND 2012/04/07 JUnit 強化キャンプ #junitbc - Togetter (写真：会場となった某漫画喫茶個室内に映し出される実践映像を眺める参加者一同) 私自身、勉強会に於いてテスト関連のイベントには参加しつつも(TDDBC等)、そこから先テストに於いて諸々を(Bootからの次の段階である)ブースト(Boost)出来ていなかったので、このイベントを見つけ次第『これは！』と思い参加してきました。 会場はまんがねっとラウム新宿本店。 自身としては、漫画喫茶で勉強会やるってのは初めてだったので、『(諸々)どうなんだろう？』という気持ちがありましたが、実際やってみると殊の外快適で"これは良い"という感じでしたね。ネット回線(立地上の問題で時々調子が悪い時があった)や部屋に対する定員を上手く調整すれば、利用場所としてはかな〜り良いものになるのでは
TDD カンファレンス 2012 #tddconf
joker1007 (アルフォートおじさん) @joker1007 自分はBDDでしっくり来たところがあって、TDDはテストって言っちゃってるせいで、何かラベルの呪いにかかってる感じはしている。 #tddconf 2012-04-06 19:51:40
電気通信大学：西 康晴 先生インタビュー：第1回：プロフェッショナルなテスト技術者になる方法 | 豆蔵ソフト工学ラボ
電気通信大学：西 康晴 先生インタビュー 第1回：プロフェッショナルなテスト技術者になる方法 印刷 株式会社豆蔵 取締役 プロフェッショナルフェロー 豆蔵ソフト工学ラボ所長 羽生田 栄一 2009/10/02 ［テスト・品質改善］ 日本のテスト業界の立役者である電気通信大学の西康晴先生にお話しを伺ってきました。 これから３回に分けてお送りしていきます。 西先生は、電気通信大でテスト技法やソフトウェア工学を中心に研究・教育活動を行うとともに、産業界におけるテストや品質の問題にも積極的に関わり、日本のソフトウェア開発をよくするためにテストという切り口で果敢に挑戦されています。ソフトウェアテストシンポジウム(JaSST) など様々なテスト関係者コミュニティの立ち上げや世話役も引き受けられ、若手エンジニアの悩み相談を受け持つ頼もしいお兄さんという側面ももっています。 今回のインタビューでは、西先
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
ブラックボックスのテスト設計手法でもコードを見なくていいわけではない - 千里霧中
要求に対する妥当性確認のような、ブラックボックスでテスト設計を行うテストでも、製品のコードや開発のコミットログは大変重要な情報になります。 理由はいくつかありますが、例えばコミットログからは以下のような情報が得られます。 単純に、コミットログ確認による変更レビューでバグを見つけられることがある。事前レビューでのバグ検出は、実際にテストを始めてバグを見つけた時より手戻り工数を削減できることが多い。またテストすべき危ない変更もレビューで検出できる。 変更の影響範囲の予測材料になる。例えば割り込み関数の変更を見つけることで割り込み発生時のタイミングの変化を予測する、といったことが可能になる。一般的に、タイミング・非同期処理・並行処理・ハードウェア起因といった、ごく稀な条件に依存するバグについては、テスト全体の網羅性を底上げするだけでは検出が難しい。そこではある程度怪しい箇所を絞り込んで探索的テス
xUTP Magazine - xUnitester Hotlinks: 第一回 和田卓人さん(下)
はじめに xUnitester Hotlinks は、毎号、著名な xUnitester にインタビューを行っていこう、という企画です。 栄えある第一回のインタビューは、日本の TDD 伝道師、和田卓人さんにお願いしました。 こちらは後編となります。前編はこちら 和田卓人さんのプロフィール 和田卓人（わだたくと） タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒する。その後様々な縁に導かれソフトウェアパターンやXP（eXtreme Programming）を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。テスト駆動開発に「完璧主義の呪い（完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念）」を解いてもらってからは、文章を書いたり、講演を行ったり、ハンズオンイベントを開催
意地悪漢字 - mkoszk’s blog
ユースケース仕様の拡張条件と拡張系列とは で、拡張条件について述べました。この拡張条件をどのように挙げたらよいのでしょうか。 コーバーンの「ユースケース実践ガイド」には次のような記述が載っています。 拡張条件の処理を考える前にブレーンストーミングを行い、拡張条件をできるだけ多く見つけ出すことが重要です。（中略） シナリオが失敗する道筋や成功する別の道筋を、ブレーンストーミングで考えられるだけ出してみましょう。次の項目をすべて考慮してください。 代替成功パス 社員がショートカットキーを使用する 主アクターの振るまいが正しくない 間違ったパスワード 主アクターが活動を停止する パスワード入力のタイムアウト 「システムは・・・を確認する」という言い回しは、拡張で確認の失敗処理を行わなければならないことを意味する。 口座番号が正しくない 支援アクターからの応答がない、あるいは応答が正しくない 応答
JUnitの知識を棚卸し #JJUG - 日々常々
Java Advent Calendar 2011の16日目です。 前：JSFUnitでテストしよう！ | Kokuzawaの日記 次：JavaEE使ってウェブアプリケーションつくろうよ - 水まんじゅう 書いてること JUnit の話です。使い始めからちょっとだけ踏み込んだ辺りですかね。ちょっとだけなので普通に使ってる方には不要な内容かと思います。私の今持ってる知識を書き殴ってみた感じになりましたが、微妙な理解と残念な文章力の相乗効果でグダグダになってます。お察しください。 内容は Assertion->カスタムAssertion、Matcher->カスタムMatcher、Rule->カスタムRule です。 Assertion JUnitは assert があってこそです。まず org.junit.Assert にある馴染み深い assert を並べてみます。 assertEquals
テストと言うパートナー #TddAdventJp - 日々常々
TDD Advent Calendar jp: 2011の 12日目です。 前：あなたは写経しますか - pocketberserkerの爆走 次：TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組 テストはパートナー 「何を言ってるんだ？」な感じかもしれませんが、私にとってテストはパートナーです。 私がTDDのコンテキストで言う「テスト」はDeveloperTestです。このテストは開発者の開発者による開発者のためのテストであり、つまり開発者たる私のためのものです。私だけのためにテストは働いてくれます。 テストに対する不安 TDDや自動テストと言う言葉に触れ、「いざテストを書こう」と思った時。もしくはよく知らないままテストコードを書かなければならなくなった時。テストに対して不安を感じると思います。TDDは「不安をテストにする」とか言いますが、そもそもテス
TDDのはじめかた #TddAdventJp - 千里霧中
本エントリはTDD Advent Calendar jp: 2011の12/8の担当分の記事で、id:t-wadaさんの「右手に感情、左手に数値 - カバレッジを味方にしよう - t-wadaの日記」に続くものです。 はじめに TDDはシンプルな原則に則った手法ですが、とっつきの悪さもしばしば持たれがちです。また一連のTDD Advent Calendarで起こった議論や会話の中でも、TDDの始め方はどうすれば良いかという話が散見されましたので、自分の担当枠では「TDDのはじめかた」についてまとめたいと思います。なお紹介するのはあくまで数ある入門方法のうちの１つです。たぶん他にも色々な良い入門方法があると思います。 全体像 紹介する入門方法は以下のようなステップバイステップの構造となります。 いつでも軽快に使えるユニットテスト環境を構築する 必要と感じたらすぐテストを活用する テスト並行を
右手に感情、左手に数値 - カバレッジを味方にしよう - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar 2011 の 7 日目の参加エントリです。前日は @sue445 さんの実録！TDD風景でした。 しかし TDD Advent Calendar 2011 は、名エントリが多いですね……ハードルが上がり続けていて胃に穴があきそうです。私の言いたいことの多くは、既に @bleis さんのTDD の基礎体力と、TDD に対する想いや、 @shuji_w6e さんのTDDを学ぶべき10の理由で語られています。二つとも素晴らしいエントリなので、ぜひ読んでみてください。 そろそろカバレッジについて一言いっておくか さて、今日書くのは、カバレッジについてです。 @bleis さんのエントリに以下のような記述があります。 もう一度言いますが、TDD のテストは Developer Testing であって、品質保証を目的としたテストではありません
JUnit のセカイ #JJUG - やさしいデスマーチ
このエントリーは、@cero-tさんのエントリーの次で、Java Advent Calendar 2011の6番目のエントリーです。自分自身の今年のメインテーマがTDD（テスト駆動開発）と言う事もあり、関連エントリーとしてJUnitについて書きたいかと思います。今更JUnit？と思われた方も普段からJUnitを使っていあなたも気軽にお読みください。尚、色々な話題を駆け足で紹介するので、どれも簡単な紹介程度になってしまいますが、ご了承願います。 JUnit4 スタイル JUnitがアノテーションに対応し結構な月日が流れましたが、古いコーディング規約のままでテストコードを書いていませんか？JUnit4では、アノテーションとアサーションを使ったテストコードを書くことが基本スタイルです。かつては、TestCaseのサブクラスを作り、testではじまるメソッドを定義していましたが、今は Testアノ
アジャイル開発でも信頼度成長曲線は有効か？ツールを使って確かめてみよう – テスト自動化他何かのメモ
続けてですが、僕も「Software Test & Quality Advent Calendar 2011」の12/2エントリーとして、書きます！ 皆さんはテストの完了条件をどのように設定していますか？ 多くはテストで発見した障害に対して、重要度もしくは優先度をつけて、 重要度高の残障害 0件 重要度中の残障害 5件 のような条件をクリアーした時に、テスト完了とすることが多いと思います。しかし、これではこれまで発生した障害のみの情報に頼ってテストの完了条件としているため、テスト完了後に発生しうるリスクに対して備えているとは言えません。 それを補完とする手法の一つとして信頼度成長曲線があります。 え、それってメインフレーム時代の大規模プロジェクトとかにしか使えないやつじゃないの？今のアジャイル開発には使ええないよね。俺はTDDで開発しているからバグ出さないぜ、そんなの関係ないよ。 とか言わ
Android の自動テストツール
原文(投稿日：2011/09/30)へのリンク Android アプリケーションで自動テストを実行するフレームワークやツールは数多い。Activity Instrumentation，MonkeyRunner，Robotium，Robolectric，他にも多数のものがある。そのひとつである LessPainful は，実際のデバイス上でサービスとして自動テスト機能を提供するツールだ。 Android には基本的な実装テストのサポートがある。そのひとつが android.test パッケージの ActivityInstrumentationTestCase2 クラスだ。これは JUnit の TestCase を拡張したもので，Android のアクティビティをテストする機能を備えている。アプリケーションのテスト時には，アクティビティの実装が Android エミュレータまたは実機上の D
TDDBC 札幌 2.1 開催しました - やさしいデスマーチ
シルバーウィークの後半に札幌にてTDD（テスト駆動開発）の体験型イベントであるTDDBC（札幌版）を開催しました。 TDDBC 札幌 2.1 であること ナンバリングが変な事になっていますが、札幌では今回で通算５回目の開催になります。近年、テスト駆動開発は開発手法として非常に重要なスキルの１つと考えられていますが、なかなか開発現場で実戦する機会はありません。自分で学習していくことも可能ですが、見よう見まねで学習するよりも同じような志*1を持っている人が集まって、同じ目標に向けて学ぶ方が効率が良いものです。1人で悩むよりもみんなで悩み、解決できるような人がイベントにいると安心ですから。 TDDBCは、テスト駆動開発を実際にやってみるためのイベントです。TDDの伝道師である id:t-wadaさんが講師を務め、午前中に座学、午後に演習というのが基本スタイルとなっています。しかし、TDDやアジャ
TDDBC お題
The document describes a WordFilter class that can detect and censor sensitive words in strings. It allows specifying words to censor, and will replace matches with <censored> in the censor method output or return true/false from the detect method. The filter is designed to find and obscure matches without disturbing surrounding context.Read less
レガシーコードをライブで扱う際のポイント試案
twitter で TDDBC Hokuriku (2010) のレガシーコード改善を Coding Dojo で行った際の Ruby チームは比較的うまくいってたけど、あれって○○な流れだっけ的な話をしているうちに気になってることをまとめておこうと思い立ったので、できるだけ書き出してみる。 何かのきっかけになれば嬉しい。 素材（レガシーコード）のポイントまず動くこと触ったことがあること1ある程度でいいので機能別に書かれていること オブジェクト指向であるとなお良い（使える技が増える）小規模であること ただし完全に単機能だと余地が少ないのでテストを足しにくい外部 API 依存しまくりの場合は単なるレガシーコード改善とはまた別なテクニックの習得に繋がってよいかも自動実行できるテストがないこと :-)1 については「えっ」て思うかもしれないけど、放置してるものは依存ライブラリの関係や、そもそも動
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
