1日たってしまいましたが、11/06にTDD Boot Camp 横浜に参加してきました。詳しい記事は、id:absj31さんの記事が素晴らしくまとまっているので、ご覧くださいませ。 TDD Boot Camp 横浜に参加してきた #tddbc - Diary of absj31 TDD BCの感想と、Groovyを初めて触った感想です Groovyペアに立候補した理由 「募集」をしているわけで、立候補すれば、その場でペア成立 Groovyを触ったことがなくても大丈夫という前提 プログラミング言語好きとしては、Groovy触ってみたかった 普通なら、師匠は直々に、言語のフォースを教えくれない 運営の方と、TDDやったほうが身につきそう！ たしか、こんな理由だったと思います。打算と興味が五分五分といったところでしょうか。運営の方が、Groovy本を持ってきてくれて、 パラパラと見た第一印象は
勤め先でTDDの講習会を行ったので、その内容について書きます。 この記事がTDD導入を検討している方の力になれば幸いです。 経緯 私はとあるSIerに務めており、部内ではテストの工数を削減することが課題となっています。 以前からTDDを同僚や先輩に宣伝していたこと、また、理解ある上司に恵まれたこともあって、 テストコードの書き方を講習する時間をもらえました。 そこで、TDDBCの要領で楽しみながらTDDを学んでもらうことにしました。 一人ではつらいので、TDDBCの参加経験がある先輩と二人で講習を行いました。 参加者について 若手開発者 3名 中堅開発者 2名 業務にオブジェクト指向の考え方を取り入れたのは2,3年ほど前?らしい。（要出典） 普段はC#、VisualStudio、VSSを使っている。 講習の目的 二人で話しあい、講習の目的を以下のように決めました。 テストコードの書きかたを
TDDBCは、みんなでTDDやってみようぜ！ペアプロとかやって他言語/他人間で 理解しあってリスペクトしようぜ！っていうワークショップです。 今回は7/9、TDDBC東京に参加してきました。 今回の発起人は@HIROCASTさんです。 HIROCASTさんのブログエントリはこちらですね。 当日のUSTの記録はこちらですね。 写真はこちらです。 @HIROCASTさん、id:t-wadaさん、スタッフのみなさん、 会場提供されたZyngaJapanさん、参加された皆さん、ありがとうございました。 かなりの参加希望者数で、ATNDは早い段階で人が溢れまくっていました。 ちなみに希望して運営のお手伝いってことで当日の受付をやらせてもらいまして、 ATNDの「設営・受付・運営協力」に「@akitsuka さん」と 書いていただいているんですが、@akitsukaさん（知らない人）は ぜんぜん別の人
TDD Boot Camp in Tokyo 1.5 に参加しました 2011/07/09 どこよりも早いブログ！・・を書こうと思ってたものの、@shinyaa31さんのブログとか@tomy_kairaさんのブログとか内容てんこもりでお届け済みなことを確認したので、僕の方は写真メインでTDD Boot Camp in Tokyo 1.5に参加してきた感想などまとめていきます。（USTの録画はこちら。@brtrvierさんありがとうございます！） 大事なことを最初に ・渋谷の会場に集まれた皆さん、ustでサテライト参加されていた皆さん、お話を熱心に聞いて頂いてありがとうございました！失敗談を交えてお話して少しでも背中を押すことができればとLTを申し出ましたが、話しているうちにやっぱり、こちらが勇気づけられているように感じました。 ・@t_wadaさん、講演ありがとうございました！いつも講演の
みなさんこんにちは。@ryuzeeです。 planetgeek.chというサイトでUrs Enzler氏がTDDのチートシートを公開していたのでご紹介します。 Clean Code and Clean TDD Cheat Sheets (PDFファイルでダウンロード可能です) 以下で、チートシート内の一部を意訳にてご紹介しましょう。 Unit Test Smellsテストが何もテストしていない一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない テストに過度なテスト準備が必要とされるテストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが本当にテストしたいのが何なのか？ということを分かりにくくする。 大きすぎるテスト有用だが大きすぎるテスト。たぶんテストが１つではなく複数の機能をチェックしているか、テストが１つ以上のことをやろう
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
７月１０、１１日に行われたTDDBootCamp名古屋に参加してきました！ http://kokucheese.com/event/index/2467/ 非常に濃い二日間はあっという間に終わってしまいました。ただ、ガッツリやっただけのことはあって得られたものも多かった気がします。 また、このTDDBootCamp名古屋が終わっての率直な感想は、「楽しかった！！でも、悔しい！！！」ってことでした。 楽しさ 1.ペアプロ初体験の楽しさ TDD体験 テストを最初に書いて、テスト実行し、レッド→グリーン→リファクタリングという黄金の回転をグルグル回すというTDDの真骨頂を体験できた。 ペアの方の、ショートカットキーでの操作、リファクタリングの仕方が段違いに早かった。そこは非常に参考になりました。 レガシーコード改善体験 人が作ったコードに対して、改善を加えるという体験は今までやったことがなかった
ソフトウェアの開発を行うときに、まずテストケースを先に作ってから機能を作り込む「テスト駆動開発」（Test-Driven Development：TDD）。これにより、ソフトウェアの開発工数や品質にはどの程度の変化があるのでしょうか。 TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ この疑問について調査した論文を、奈良先端科学技術大学院大学 助教の森崎修司氏が3月10日のブログ「国立大学法人奈良先端科学技術大学院大学 助教」のエントリ「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」で紹介しています。 開発時間はやや増えたがコードの品質は上がった 論文全文は有料なので読めないものの、森崎氏のブログによると次の知見が得られたとのことです。まず、ソフトウェ
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
ついったーにつぶやいたものを中心にまとめました。 まだこれで正しいという確信を持てていないので、メモという位置付けでお願いします*1。 なので追記する可能性が高いです。 TDD でドキュメンテーションコメントを書くタイミング カテゴリを指定して実行するテストを分ける git stash の使い道 TDD でドキュメンテーションコメントを書くタイミング ここでは Git を前提にしますけど、rebase 使えるならほかのものでも大丈夫なはずです。 TDD でいつドキュメンテーションコメントを書けばいいのか、というのは、 Re:TDD を理解するためのまとめ - ぐるぐる〜 TDD Boot Camp の参加報告とか読んで - ぐるぐる〜 と、過去 (といっても半年も経ってないけど) ずっともやもやしてたんですが、 事前条件で楽できないかなーという考え - Logic Dice に対する自分な
自由回答欄がいい感じにいい感じなので、だーっとコピペします。 引き続き、このアンケートにご協力頂けるかたを募集しています。TDDBC北陸に参加してみたい方はもちろん、興味はあるけど参加はできなさそうな方なども、ぜひご協力ください。 アンケートは => http://bit.ly/6ToL7W イベントの参加募集は、1/12くらいから始める予定です。参加表明っぽい設問がありますが、改めて募集しますので、今しばらくお待ちください。顔。 あなたが自動テストを使って開発しているなかで、課題となっていることがあれば、教えてください。 TDDを既に実践している テストの資産価値。今後役に立たない/足枷となるテストをいかに捨てるか。 スローテスト。 テストしにくいもののテスト。JavaScript や GUI など。 「テスト」という用語がもたらす誤解。お客様には品質保証として捉えられがち。都度説明して
ＯＯエンジニアの輪！ 第 43 回 和田卓人 さんの巻 今回のゲストは、和田卓人 さんです。テスト駆動開発の紹介など様々な活動で知られています。 ■ はじめに --- まこたんさんとのつながりは たぶん arton さんがまこたんを紹介した絡みに似てるかもしれないんですけど、以前「Seasar のからさわぎ」とか、 Seasar*1 のコミュニティが、よく飲み会やってたんですね。初めて会ったのもたぶんこの辺りだったと思う。 --- 2005 年ぐらいですか… ヨーロッパ選手権が 2004 年だから…… 2004 年、 2005 年ぐらいですね。 僕はサッカーが好きなんですが、サッカーファンというものは 2 年単位で年を覚えていられるんです。 4 年単位でワールドカップがあって、さらにそこから 2 年ずれて 4 年単位でヨーロッパ選手権があるので、大体あの時に何やってたってのは 2 年刻みで
本日はオブジェクト倶楽部夏イベントにて 90 分もの長時間(!)喋らせていただきました。 会場にてお聞きくださった皆様、ありがとうございました。 講演の内容はというと、「創発的設計 (Emergent Design) 」というコンセプトについて講演をさせていただきました。自分は何を学んできたのか、何に学んできたのかを明かにし、いまの理解を立体化しました。「テスト駆動開発を本当に厳格に行うならば3イテレーション程度でアーキテクチャが破綻する」という意見に対する私の考えの表明でもあります。 Emergent Design - ObLove 2009 summerView more documents from t_wada. テスト駆動開発者はテスト駆動開発という手段だけで開発を行っている、つまり先行設計をしない、という誤解に対して、そのようなことはないという (ごく真っ当な) 結論になってい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く