テスト駆動開発入門ネクストステップ
テスト駆動開発入門ネクストステップ 1. テスト駆動開発入門 ネクストステップ 井芹洋輝 TDD Boot Camp 東京 for C++ 2011/10/8 @国立情報学研究所 2. 謝辞 • 主催の今給黎さん • 和田さん、会場提供、スタッフの方々 • 参加者の皆さま 深くお礼申しあげます 3. 自己紹介 • 井芹 洋輝(@goyoki/id:goyoki) • 組み込みエンジニア • WACATE実行委員/TDD研究会 • 講演/執筆： – XP祭り関西「ユニットテストの保守性を作りこむ」 – Androidテスト祭り「テストの活用による開発効率化」 – 並カン「FPGA/HDLを活用したソフトウェア並列処理の構築」等 4. 概要 本講義はTDDの基本サイクルを学んだ方 が対象です。 本講義ではTDDを開発で実践するための 知識、TDDについて自立して学習を進め るための情報を学び、
拡張型TDD@JaSST'11 Tokyo
VOTDD(検証指向TDD) [JaSST’12Tokyo, TDDの守破離 on live, 破H Iseri1.6K views•16 slides
テスト駆動開発の効果はどのくらいある？
ソフトウェアの開発を行うときに、まずテストケースを先に作ってから機能を作り込む「テスト駆動開発」（Test-Driven Development：TDD）。これにより、ソフトウェアの開発工数や品質にはどの程度の変化があるのでしょうか。 TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ この疑問について調査した論文を、奈良先端科学技術大学院大学 助教の森崎修司氏が3月10日のブログ「国立大学法人奈良先端科学技術大学院大学 助教」のエントリ「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」で紹介しています。 開発時間はやや増えたがコードの品質は上がった 論文全文は有料なので読めないものの、森崎氏のブログによると次の知見が得られたとのことです。まず、ソフトウェ
TDD Boot Camp
This document discusses an algorithm called FizzBuzz and includes links to articles about it. It also discusses using a Last Recently Used (LRU) cache to track recently accessed data and remove the least recently used items when the cache reaches capacity. Code examples are provided for implementing an LRU cache using a Map data structure.Read less
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
テスト駆動開発（TDD）の事例 - IBMとMS 計4プロジェクトを紹介した論文 -：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
*はbiac氏のご指摘により「TDD採用により増加した工数」から修正した。 欠陥密度はリリースが近いフェーズでのテストで検出された欠陥にもとづいているそうだ。 また、次のような知見が紹介されている。 途中でTDDをやめたり、途中からTDDをはじめてもうまくいかない。プロジェクトの開始時からやるべき（既存のソフトウェアの次バージョンから始める場合には言及がない） テストコードの実行速度に気を配り、速く実行できるようにする。それぞれのテストコードの実行は短くても結合すると膨大な時間になってしまう場合がある。 テストケース数、テストコードの行数、コードの行数、カバレッジ、発見されたバグと修正されたバグの数、を計測し、傾向を把握する。 開発開始、終了時には開発者の意向に耳を傾ける場を作る。今後も継続してTDDしたいかどうか。 どのプロジェクトもTDDを採用されなかったと想定した場合と比較して、工数
TDD Boot Camp の参加報告とか読んで - ぐるぐる～
TDD Boot Camp には行っていないんだけど、参加者のエントリを色々読んで触発されたので思っていることをちょこっと書いておきます。 日曜日は id:a-hisame に無理言って色々と聞いた*1しね！ 以下引用が多くて微妙に長文。 アクセス修飾子 デモ：coberturaに機能追加する*1 テストできそうな箇所を小さい範囲にメソッド抽出 さらに、副作用がある箇所をprotectedメソッドに抽出 サブクラスで副作用メソッドをオーバーライドして無効化 テストのために、検出用変数をprivateからpublicに変更 検出用変数にアクセスして、assertを記述 *1: この辺ちょっとうろ覚え。もし間違っていたらご指摘ください。 TDD Boot Campに参加しました - @ikikko のはてなブログ これの 4 と 5 なんだけど、個人的には package private でい
僕がTDDをやめた理由 - カタチづくり
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
アプレッソ開発チームのブログ : FEST-SwingでFestival!
2009年11月16日20:48 カテゴリ FEST-SwingでFestival! アプレッソ・バランスボール愛好会の"よう"です。 先日、「FEST-SwingでFestival!」というタイトルで「xUnit Test Patterns 読書会」でGUIテストについて発表してきました。 DataSpiderチームではGUIのテストをFEST-Swingを使って行っています。 DataSpiderのようなGUIアプリケーションではUnitテストだけでは、十分なテストを行うことができません。GUIのテストはどうしても人手でテストする必要があります。 GUIのテストは単調な作業を人手で行わなければならず、時間のかかるとても骨の折れる作業でした。そこで私たちは、その作業を軽減するために、GUIテストの自動化に取り組んできました。 発表では、GUIテストを行うまでの経緯と私たちの取り組み、そし
Google App Engineでテスト駆動開発を行うための3つのTips | TRIVIAL TECHNOLOGIES 4 @ats のイクメン日記
Google App Engineの開発ではPythonを使います。GAEを使ったWebアプリの開発でテスト駆動開発を行う際にも，Python的なユニットテストの文脈を活用できます。 ただし，GAEでユニットテストを行うためにはいくつかのツールやトリックが必要です。ここでは，そのテクニックを簡単に紹介します。 その1 : NoseGAEを使う Pythonのテスト用ツールにNoseがあります。このツールは，複数のディレクトリを渡り歩いて，複数のテストコードを一気に実行してくれる便利なツールです。 NoseのプラグインNoseGAEをインストールすることで，GAEアプリのテストを楽に行うことができます。「nose --with-gae」というようにオプション指定をすることでNoseGAEを利用できます。NoseGAEでは，テストコード上でGAEのモジュールやパッケージをインポートするために必
はてなブログ | 無料ブログを作成しよう
うまくいかない日に仕込むラペ 「あぁ、今日のわたしダメダメだ…」 そういう日は何かで取り返したくなる。長々と夜更かしして本を読んだり、刺繍をしたり…日中の自分のミスを取り戻すが如く、意味のあることをしたくなるのです。 うまくいかなかった日のわたしの最近のリベンジ方法。美味しいラペを…
TDDが失敗する時 - Kazzz's diary
TDD(Test-Driven Development)は良い開発手法だが、以下の場合に合致するシステムの開発では使わない事を薦めている。なぜならば破綻する可能性が極めて高いからだ。 設計が不完全で仕様に抜けがあることが明らかな場合 これは自明だろう。インタフェースさえ決まればテストが書けるTDDでも、抜けてしまった仕様はテストとして書けない。TDDは仕様の変更には強いが、だからといって仕様の抜けにも強いとは言えない。 仕様とソースコードのレビュー時間が取れない場合 レビュー時間が取れない? そんなバカなと思うが、そういうシステムを見ることは結構多い。仕様のレビューやすり合わせは結合テストをしながら行うのが当たり前と考えているような現場ではTDDは上手く回転しない。 既にスケジュールが大幅に遅れている場合 スケジュールがタイトな開発の現場では、一度取り戻せない規模の遅れが出てしまうとその後
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDD Boot Camp を開催させていただきました - t-wada の日記（旧）
http://d.hatena.ne.jp/kikaineko/20041128