1. JS開発における TDDと自動テスト ツール利用の勘所 2012.12.06 株式会社マピオン 中村 浩士 12年12月5日水曜日 2. 自己紹介 中村 浩士 ( @kozy4324 ) 株式会社マピオン所属 主にWebアプリのフロントエンド開発 JavaScript, ActionScript 12年12月5日水曜日
1. JS開発における TDDと自動テスト ツール利用の勘所 2012.12.06 株式会社マピオン 中村 浩士 12年12月5日水曜日 2. 自己紹介 中村 浩士 ( @kozy4324 ) 株式会社マピオン所属 主にWebアプリのフロントエンド開発 JavaScript, ActionScript 12年12月5日水曜日
朝ごはんをぎりぎりで食べて、直接会場に。 当日の発表資料はこちらです。 TDD Boot Camp福岡2日目 View more presentations from bleis tift 秋猫さん (id:Akineko) の発表の中で SQL で FizzBuzz やるとか SQL で bf 処理系作るとかそんなの絶対おかしいよ! て言われた気がしますけど全然おかしくないよ普通だよ! お昼ご飯を食べて、午後からは新しい仕様を言い渡しました。 Web サービスからつぶやきを取ってきて、それを判別 非公式 RT も判別 現在の時刻前後 30 分の時間帯のつぶやきの判別 これに伴い入力形式を変更 「yyyy/MM/dd HH:mm:ss\tScreenName\tBody」 この変更は結構厳しかったみたいです。いろんなところから悲鳴の声が。 三番目のお題のために和田さん (id:t-wada
ここ(本ブログの過去エントリ)で、IBMとMSでのTDD(Test Driven Development)の適用評価事例を報告する論文を紹介した。TDDの適用評価は他にもあり、ここで紹介するのも、そのうちの1つ。 Boby George, a and Laurie Williams: A structured experiment of test-driven development, Journal of Information and Software Technology Vol. 46, No. 5, p. 337-342(2004) 論文では、24人の実務経験者を対象にテスト駆動開発をした場合としなかった場合(設計→実装→テスト)の比較をしている。報告されている主な知見は以下のとおり。 TDDを実施した場合に機能テスト(ブラックボックス)で不具合を検出するテーストケース数が削減さ
*はbiac氏のご指摘により「TDD採用により増加した工数」から修正した。 欠陥密度はリリースが近いフェーズでのテストで検出された欠陥にもとづいているそうだ。 また、次のような知見が紹介されている。 途中でTDDをやめたり、途中からTDDをはじめてもうまくいかない。プロジェクトの開始時からやるべき(既存のソフトウェアの次バージョンから始める場合には言及がない) テストコードの実行速度に気を配り、速く実行できるようにする。それぞれのテストコードの実行は短くても結合すると膨大な時間になってしまう場合がある。 テストケース数、テストコードの行数、コードの行数、カバレッジ、発見されたバグと修正されたバグの数、を計測し、傾向を把握する。 開発開始、終了時には開発者の意向に耳を傾ける場を作る。今後も継続してTDDしたいかどうか。 どのプロジェクトもTDDを採用されなかったと想定した場合と比較して、工数
TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ
原文(投稿日:2009/11/04)へのリンク "TDDによってペースが鈍ると考えている人は石器時代で生きつづけているようなものだ"と主張したことで議論を巻き起こしたブログに続き、Bob Martin氏は現実のTDDの適用可能性、役割、恩恵に対する深い洞察を試みている。 氏はまず"TDDはアーキテクテャの代替物か?"という大きな問題を取り上げ、実例を背景に「そうではないですが、しかし...」と答えている。 いちから始めて次々にテストケースを書いていくことで実行可能なアーキテクチャを生成できるという意見は全くばかげたことです。テストしないという決断を下す必要もあります。 もちろんこれらの決断の多くはできるだけ先延ばしにすることができるし、そうすべきです。例えば、データベーススキーマは恐らく長い時間待つことが可能なものです。Spring、JSF、Hibernate、JPAなどを使うかどうかの決
本日はオブジェクト倶楽部夏イベントにて 90 分もの長時間(!)喋らせていただきました。 会場にてお聞きくださった皆様、ありがとうございました。 講演の内容はというと、「創発的設計 (Emergent Design) 」というコンセプトについて講演をさせていただきました。自分は何を学んできたのか、何に学んできたのかを明かにし、いまの理解を立体化しました。「テスト駆動開発を本当に厳格に行うならば3イテレーション程度でアーキテクチャが破綻する」という意見に対する私の考えの表明でもあります。 Emergent Design - ObLove 2009 summerView more documents from t_wada. テスト駆動開発者はテスト駆動開発という手段だけで開発を行っている、つまり先行設計をしない、という誤解に対して、そのようなことはないという (ごく真っ当な) 結論になってい
Welcome to our site! We cover all aspects of automated testing, from TDD/Unit testing to System Testing and Continuous Integration. Please contact us with any questions or suggestions. - Eric Vautier, David Vydra Surely such an attitude cannot continue to exist in delivering software that is increasingly underpinning business critical applications * October 7, 2008 A study into the views o
ASP is Working! Hostname: IIS6P Pool URL: junitmax.com Local address: 10.4.79.1
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する? - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く