「とちぎテストの会議」レポート | gihyo.jp
2010年7月17日に、栃木県北部の西那須野公民館に30名近くの人が集まり、「とちぎテストの会議」が開催されました。本稿では、本イベントのレポートをお届けします。 本レポート写真協力：佐々木揚さん、中内章一さん 深夜のTwitterから始まった、とちぎテストの会議 本イベントは、2月ごろにTwitter上でTDD（テスト駆動開発）をめぐる議論が行われたことが発端となっています。同じ「TDD」という言葉を見たときに想像する内容が人によって大きく異なるらしい、ということがこれらの議論から見えてきたため、「それなら、様々な立場の人を集めて議論してみよう」というところから本イベントが企画されました。 TDDはテスト手法か否か（@kdmsnrさんまとめ） TDDについて（@t_wadaさんまとめ） 深夜のテストTL（@fistfvckさんまとめ） TDDネタ再燃？（@vestige_さんまとめ）
卒研
卒業研究にご協力のお願い 現在、卒業研究でテスト駆動開発（以下TDD）の初心者と経験者（上級者）のプロセスについて研究しています。 しかしながら、私のまわりにはTDD経験者・上級者がほとんどおらず、データを集めるのが困難です。 そこで、TDDに自信がある方にはデータ収集にご協力いただければ幸いです。 内容など JUnitLogGetを導入した状態で、4つの課題についてTDDで作成してください。課題に関しては後述します。 「課題」と記述している理由は、これらのプログラムが佐賀大学理工学部知能情報システム学科3年次実験科目「システム開発実験」の演習課題の一部だからです。 課題はすべて30分～1時間以内で作りあがる程度のプログラムです。 JUnitのバージョンはどちらでも構いませんが、できればJUnit 3でお願いします。 作成が完了したら、JUnitLogGetによって出力された
TDD Boot Camp北陸に参加してきて - M-Tea
TDD Bootcamp の体験談を聞いていたら、是非参加してみたいとおもっていました。 そうすると、 TDD Boot Camp 北陸 なるものが開催されるということで、参加してきました。 北陸エンジニアグループ,katzchangさん、t_wadaさん、その他参加者の皆さんありがとうございました。 TDD BootCampに参加して TDDと自分 じつは、TestUnitがある！ということ、TDDという言葉がある事は知っていましたが、 実際にTDDを実体験するのは初めてでした。 そんな自分が、今回TDD Boot Camp 北陸に参加して、疑問に思う事を沢山質問してきました。 その一部を記録として残しておきたいと思います。 TDDで生じた疑問とその議論結果 講演、実際のペアプロを2回で疑問に思った事とその議論結果についてまとめておきます。 t_wadaさんを含め、議論に参加頂いた方に感
テスト駆動開発（TDD）の事例 - IBMとMS 計4プロジェクトを紹介した論文 -：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
*はbiac氏のご指摘により「TDD採用により増加した工数」から修正した。 欠陥密度はリリースが近いフェーズでのテストで検出された欠陥にもとづいているそうだ。 また、次のような知見が紹介されている。 途中でTDDをやめたり、途中からTDDをはじめてもうまくいかない。プロジェクトの開始時からやるべき（既存のソフトウェアの次バージョンから始める場合には言及がない） テストコードの実行速度に気を配り、速く実行できるようにする。それぞれのテストコードの実行は短くても結合すると膨大な時間になってしまう場合がある。 テストケース数、テストコードの行数、コードの行数、カバレッジ、発見されたバグと修正されたバグの数、を計測し、傾向を把握する。 開発開始、終了時には開発者の意向に耳を傾ける場を作る。今後も継続してTDDしたいかどうか。 どのプロジェクトもTDDを採用されなかったと想定した場合と比較して、工数
【連載◎開発現場から時代を眺める by arton】第2回
【連載◎開発現場から時代を眺める by arton】第2回 テスト駆動開発（TDD）が分かると従来の設計手法の問題が見えてくる（前編） 本稿では，テスト駆動開発（Test-driven Development――以降TDDと略す）について解説する。TDDは，その名の通りテストを主としてプログラムを開発する手法だ。ここで重要なのは，TDDはテスト手法ではないということだ。では何かと言えば，TDDはその名の通り開発手法なのだ。さらに正確に言えば，プログラムの開発工程を設計，実装，テストの3段階に分割した場合の最初の段階，すなわち設計を主眼とした開発手法なのである。その意味では設計手法と言い切ってもそれほど間違いではない。TDDによってプログラムの開発工程（設計，実装，テスト）がイテレーション（反復）される以上，最初に来る「設計」がTDDの主眼となることはある意味当然のことだ。 本稿の目的は，T
プログラミング初等教育とTDDの相性は最高
1年半ほど前、入社前はプログラミング経験ゼロの@chibisayoを新入社員としてチームに迎え、私がOJT担当っぽくなった時の経験から、プログラミング初等教育とTDDの相性は最高であることをきちんと文章に残しておきたかったので、このビックウェーブに乗ることにしました。
最近の TDD 議論についてちゃんと僕の気持ちを書いてみる - 宇宙行きたい
最初に ちょっと最近，ドタバタしてて twitter だと腰を据えて話せないなと感じたので，ちょっと最近のTDD 議論についてちゃんと僕の気持ちを書いてみようと思います． これは僕が"今"感じてる事とか考えている事を書いているだけですので，誰かを論破したいとか，誰かを説得したいという意思は無いです． 本当に裏とかはなく，純粋に「"庄司嘉織"という人間は"今この時"にこういう事を感じてこういう事を考えた」というだけです． もちろん明日には考えが変わるかもしれないし，逆に過去の発言とは違うかもしれませんが，「最近はこう感じている」という事をちゃんと書いておこうと思いました． デブサミでの発表について id:babie さんにちゃんと返事をしていなかったので，まずちゃんと返事をしておこうと思います．(遅くなってしまってすいません) @kakutani は興味なくても、あのスライドだと @yosh
1/30 RubyとTDDに関する勉強会、やります。
勉強会を開催する手はずが、やっと整いました。 10名前後、身内を中心にしてやる、小さな勉強会です。 THRIVE ON DEVELOPMENT あちこちの勉強会に参加して自分が色々なものを受け取るのはいいのですが、それに伴って「自分も伝えられるものはないのか？」というフラストレーションが高まり、重い、ほんっとに重い腰をやっと上げることができました。 年齢的にも、きちんと次の世代に色々なことを伝え残したい、という年齢にもなってきました。なにより、自分の直上の世代がそういう活動が手薄な世代だったので、強くそう思う傾向があるのかもしれません。 そして、いつかは働く開発者による働く開発者のためのGEEK Stationをつくってみたい、その思いへの、小さな小さな、ほんとに小さいけれども、第一歩じゃないかとも思っています。 コンセプトは、「手作り」と「技術も魂も」です。 テーマは Start! Ru
Growing Object-Oriented Software, Guided by Tests
Recently I have came across an excellent book on how to develop code with testing in mind, and I wanted to share it with you. The book is called Growing Object-Oriented Software, Guided by Tests and is written by Steve Freeman and Nat Pryce. The book starts right at the beggining as to why we want to develop test first and covers advanced topics such as testing persistance, threads, and asynchrono
11日目: ユニットテスト
今日は、完全に異なる内容: 自動化されたテストを語ります。このトピックの内容はとても大きいので、すべての内容をカバーするのに2日まるごとかかります。 Arkのすべてのテストは、慣習的にプロジェクトのt/ディレクトリに設置されます。 今日はユニットテストをカバーし、明日は機能テストに専念します。 ユニットテストを書くのはWeb開発のベストプラクティスの中で実行するのがもっとも難しいことです。 Web開発者は作品をテストすることに本当に慣れていないのと、たくさんの疑問がわき上がります: 機能を実装する前にテストを書かなければならないのか？何をテストする必要があるのか？テストはすべての単独の~エッジケース~をカバーする必要があるのか？ すべてにおいてよいテストをできる方法は？しかし通常、最初のテストははるかに基本的です: どこで始めるのか？ 私たちがテストを強く推奨しているとしても、Arkのアプ
PostgreSQL Conference 2009 Japanに参加 - m-takagiの日記
JPUG10周年記念のPostgreSQL Conference 2009 Japan、2日目だけ参加してきました。 主な目的は二つ。 英語のプレゼンをたくさん聞いて、耳を慣らす JPUG文書・書籍関連分科会の本田さんにご挨拶する 英語 というわけで、海外からのスピーカーのお話を中心に聞いてきました。初日と違って通訳なしだったので完全に自分の耳だけで勝負しなければならず、かなり体力を消耗しました……。 いくつか聞いたなかで、David E. Wheeler氏のプレゼンが特にすばらしかったのでここで紹介しておきます。 データベースのユニットテストをしよう！ 内容自体はごく一般的なTDD入門ネタで、特に目新しいものではありません。 「テストを書くのは時間がかかるし面倒だ」 「テストしたところでバグを見つけることはできないよ」 「こんなシンプルなコード、わざわざテストするまでもないよ」 「あまり
日記/2009/09/24/TDDについて偉そうな事書いてしまったけど - Glamenv-Septzen.net
数量的な根拠も何も無いので、単なる印象論と言われてしまえば返す口もない。 日記/2009/09/23/TDDの導入についての一考察 ふと思ったけど、TDDの所を「OOP」に読み替えれば、丁度Javaが流行出す前は同じような話があったのではないだろうか。要するに高い技術力とモチベーションを持った人間が継続して参画しないと、新しい技術は中々浸透しづらいという一般的な話になる。 じゃぁなんでOOPが浸透したかというと、これはOOPというよりはJavaやC++が浸透したので、必然的にOOPも浸透したと言っても良いのじゃないか。ライブラリがVisualC++のMFCであったり、VisualBasicのOOP実装であったり、WindowsのActiveXに浸透しているオブジェクト的な考え方であったりして、それを使って仕事をする為には半ばやむなくOOPを学習せざるを得なかったのではないか。 と言う事はT
和田卓人――TDD伝道師を生んだ読書会と「心の師匠」 － ＠IT自分戦略研究所
あなたも＠ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある！ コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中 時代は、UMLが出始め、オブジェクト指向が全盛期を迎えたころ。大学生の和田氏はマーチン・ファウラー氏の著作『アナリシスパターン』に出合った。同時期、難解なことで有名なこの書籍を読もう、という読書会がオージス総研のWebサイト「オブジェクトの広場」で企画される。「参加してみよう」――これが、和田氏の読書会初体験となった。 2000年に開催されたこの「アナリシスパターン読書会」には、錚々（そうそう）たるメンバーが参加していた。『アナリシスパターン』の翻訳を担当した友野晶夫氏と児玉公信氏、オブジェクト指向開発の泰斗である藤野晃延氏や平澤章氏……。和田氏にとって、彼らは「雲の上の存在」だ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「第14回澁谷鮫」 参加申し込み
Move over Java, I have fallen in love with JavaScript
今読んでる本 - 『テスト駆動開発入門』
ソフトウェアテストPRESS vol.1 - テスト駆動開発と単体テストのカンケイ - ソフトウェアテストの勉強室
日記/2010/02/24/TDD雑感 - Glamenv-Septzen.net
Amazon.co.jp: Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck)): Steve Freeman, Nat Pryce: 本
ソフトウェア品質の神話に関する実証的研究
