タイトル TDD 現場・導入の進め方講座 ~ TDDの学習フィードバックループの障害を取り除くコツをお伝えします ~ 概要 講師が、永和システムマネジメントでのエンジニア経験や、TDDコーチ、アジャイルコーチの経験をもとに、TDDを始める際のよくある障害と対策を、ワークを交えながらお伝えします。 導入によくある障害 Unit Testing、TDD未経験 で 頭と手が動かない。 スケジュールプレッシャーで「時間がない」 予期せぬタイミングで「割り込み」が入って対応に追われる。 「支援者」がいない。 新しい習慣が身に付く前に、今までのやりかたに戻ってしまう。 既に運用中のサービスがある。テストがない状態であるが、どっから手をつけたら良いか判断がつかない ヘロヘロScrumに躓いた。 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?FlaccidScrum
瀬良 @shela_ @irof publicからprivateを含めて検証するのと、private単体だけで検証するのであれば、先にprivate単体で検証しておいた方が安心感があると思う 2012-08-25 16:38:24
このエントリーは、@cero-tさんのエントリーの次で、Java Advent Calendar 2011の6番目のエントリーです。自分自身の今年のメインテーマがTDD(テスト駆動開発)と言う事もあり、関連エントリーとしてJUnitについて書きたいかと思います。今更JUnit?と思われた方も普段からJUnitを使っていあなたも気軽にお読みください。尚、色々な話題を駆け足で紹介するので、どれも簡単な紹介程度になってしまいますが、ご了承願います。 JUnit4 スタイル JUnitがアノテーションに対応し結構な月日が流れましたが、古いコーディング規約のままでテストコードを書いていませんか?JUnit4では、アノテーションとアサーションを使ったテストコードを書くことが基本スタイルです。かつては、TestCaseのサブクラスを作り、testではじまるメソッドを定義していましたが、今は Testアノ
2011年7月2日に開催されたTDDBC仙台のレポート。 導入 「TDD Boot Camp」通称TDDBCにはずっと参加したいと思っていたわけですが、今回仙台で機会を得ることができました。最初はJavaでと思っていたのですが、Scala組に入れて頂きまして、山中(@ymnk)さん、武田(@takedasoft)さんと3人でチームを組んでペアプロという貴重な体験をさせて頂きました(どうもありがとうございました!)。最終的には仕様変更2が何となくかたちができたところで時間切れとなりました*1。 プログラムが組み上がっていく過程や、興味深いリファクタリング、うっかりテストを書かずにコードを修正してしまったことによるバグの埋め込み、モックを使ったタイマー処理の分離など、非常に興味深い体験を数多くさせて頂きましたので、ここにご報告させて頂きます。なお、作業中のコードは記憶を頼りに書いていますので、
車窓からのTDD [PDF形式 126 KB] 最近話題沸騰(?)のテスト駆動開発について、 ko-chan(北野)と平鍋の二人が実際にTDDを行っている所を実況中継したいと思います。 TDDが行われた場所は、二人が出張から帰る「加越」という特急電車の中。 さて何が行われたのか?
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ、第2イテレーション』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 #coffee.rb の写経会に招かれた(というよりは押しかけた?)ので、先日の RSpec チュートリアルの続きを記します。このエントリは写経会に参加しながらのライブ更新でした。 (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 前回終了時点のコードと実行結果 前回終了時点でのコードを以下に記します。 message_filter.rb class MessageFilter def initialize(word) @word = word end def detect?(text) text.include?(@word) end end message_filter_spec.rb r
モックライブラリ使ってますか? 僕はJavaの人なので、主にJUnitを使ってテストコードを書いています。テストコードを書いている最中、「もしこのオブジェクトから例外が帰ってきたら、ちゃんと例外のハンドリングができてんの?」等々、既存のオブジェクトの振る舞いを差し替えたくなることってありませんか?そういうときにモックライブラリを使うと、既存のオブジェクト処理を差し替える事ができます。 実は最初はモックライブラリって意味あるの?と懐疑的だったんです。どういうところに懐疑的だったかというと、 テストコード中に出てくるモックライブラリのセットアップがめんどい。 テストコードがプロダクトコードの実装に依存しちゃうんじゃないの?プロダクトコードをちょっと変えただけでテストが落ちるようになるんじゃないの? みたいなところです。でもMockitoというモックライブラリを使ってテストコードを書き初めてから
こんにちは。nayです。TDDと出会ったのは6年以上前ですが、最近、やっと"友達"になることができました。 テストを楽しく積極的に書く心境になれるかどうかは、気だてや価値観や根性の問題ではなく、テクニックの問題であると思います。そこで、テスト嫌いの私がどうやってTDDと友達になれたかを、3つのポイントに絞ってご紹介したいと思います。 1. 関心事だけをテストする 2. DRYにする 3. RSpec 私がテストが嫌いになった理由の一つは、コード変更時にテストが足かせになることです。出るべくして出たエラーはありがたいのですが、関係ない部分で大量にエラーが出ると直すが大変で嫌になってしまいます。また、直そうとしたときに、テストのコードが読みにくいと、難行苦行に直面することになります。最初の2つのポイントは、このようなテストの「丈夫さ」と「読みやすさ」に関わるコツです。 関心事だけをテストする
日本PostgreSQLユーザ会北海道支部 / Ruby札幌 合同セミナーを見て、TDD(テスト駆動開発)について思ったことをもう少し。 テストの分類(スライドの43ページ目)が個人的には衝撃的だった。 Developer Testing(開発促進のためのテスト) Customer Testing(進捗管理のためのテスト) QA Testing(品質保証のためのテスト) ウォーターフォール脳でアジャイル開発に手を出したときの落とし穴はここだったのかと膝を打った。それはもう何回も。 伝統的なスタイルの単体テストは3なんだよね。品質保証。で、アジャイル開発でいうところのテストファーストってやつは1のことだったわけだ。そりゃ噛み合わないはずですよ。 TDDのテストを書くトリガって、「基本的な要件だから」とか「このへんがちゃんと動くか不安だから」とかだと思うんだけど、品質管理屋の目で見るとそのやり
テストとテスティング XPの出現以来、それ抜きの開発は考えられないほど、テスティングフレームワークは必須のものとなりました。 「テスティングフレームワーク」 しかし、この呼び方になにやらうさんくさいものを感じる人もいるでしょう。 なぜ、「テスト」ではないのか? ここでは、テスティングという言葉の感覚を伝えたいと思います。 なお、アジャイル開発における「言葉」についてはAgileNaKotoBaを参照してください。 テストとはなんでしょうか? 私たちが日常的に利用する「テスト」という言葉は、品質保証テストのように、既に存在する仕様に基づいて実装された完成品が、基準を満たしているかを検査するという意味で使います。 同じように学校の期末テストは、既に学習した内容が学生の身についているかを判定します。 ここにあるのは、静的な基準であり、テストは既に完成した製品や知識に対して動かしがたい事実の判定を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く