はじめの一歩からわかる「TDD Boot Camp」の開き方 #tddbc | DevelopersIO
皆さんはTDDBCというイベントをご存知でしょうか？非常に人気のあるイベントですが、その反面都市部での開催だとあっという間に枠が埋まってしまい、参加したくてもできないということも多いのではないでしょうか。そんなあなたにオススメなのが「自分でTDDBCを開いてしまう」ことです。本エントリでは、新潟県長岡市で2回のTDDBCを開催した筆者の経験を元に、TDDBCを開くにはどうすれば良いのか紹介します。 皆さんはTDD Boot Camp(TDDBC)というイベントをご存知でしょうか？ TDDBCはTDD(テスト駆動開発)について一から学べるイベントです。実際にどのようなイベントなのかは公式サイトから引用します。 TDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とする
「愛せないコードを書くには人生はあまりにも短い」というタイトルで TDD について講演させていただきました #TddAdventJp #devlove2012 - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar jp: 2012 の 17 日目の参加エントリです。前日のエントリは [twitter:@shuji_w6e] さんの「軽量なテスト駆動開発を目指して」でした。 久しぶりのエントリです。久しぶりどころか、なんと日記の更新が一年ぶりになってしまいました……(もはや年記ですね)。 昨日、二日間開催された DevLOVE 2012 の二日目最後の(?)講演として、「愛せないコードを書くには人生はあまりにも短い」というタイトルで TDD について講演をさせて頂きました。 DevLOVE では何度か登壇の機会を頂いているのですが、昨日はいつもとは少しだけ違いました。その違いとは「イベントで私以外にも TDD の事を講演する人が複数いる」ということでした。諸橋さん([twitter:@moro])の「テストに開発をもっと駆動させたい」と和智さん
JUnit実践入門 xUnitTestPatternsで学ぶユニットテスト
Team Foundation Server 2015 Update 2.1�アップグレード 手順書�～ Team Foundation Server 2...Masaki Takeda
TDDはYAGNIに矛盾する？ - カタチづくり
Joel on Softwareに面白そうな記事が載っていた。 とはいえ、どうも僕の英語力では完全な読解が難しい。会話を書き起こしたものなので当然ながら文体が会話調で、僕にはなかなか理解が難しいのだ。以下で僕の読み間違いがあれば指摘して欲しい。 さて、冒頭で Joel 氏はこう言っている。 Joel: There's a debate over Test Driven Development... should you have unit tests for everything, that kind of stuff... a lot of people write to me, after reading The Joel Test, to say, "You should have a 13th thing on here: Unit Testing, 100% unit tests
TDDをはじめる条件 #tddbc #tddconf - やさしいデスマーチ
色々と忙しすぎてブログが書けません。 JavaOneの話とか、JUnitの話とか色々書きたいんですが…もうしばらく我慢なのです。 で、TDDの前方依存と後方依存で意見が欲しいとのことなので自分なりの意見を。 技術的な前方依存 『TDDを始める前と終TDDを実際やるために必要な技術』 ・最低限対象言語でコードがかけるようになって ・最低限テスティングフレームワークを使えるようになって ・リファクタリングをしっかり学んで ・対象言語でのきれいなコード、設計とは何かを知って ・テストファーストを知って こうしておそらくスタートライン。 自分はこれは疑問です。 最後の「テストファーストを知って」という部分はTDDに関することですけど、それ以外ってTDDを始めるスタートラインではなく、ソフトウェア開発としてのスタートラインかと思います。 言い換えると 最低限対象言語でコードを書けないと、ソフトウェア
xUnit成熟度モデル 〜あなたの組織はどのレベル？ - 谷本 心 in せろ部屋
本エントリーは、Software Test ＆ Quality Advent Calendar 2011の10日目です。 http://atnd.org/events/22833 前の9日目は @m_seko さんの 「負荷テスト対象のWebアプリがこういう非機能要件(＋α)を備えていたらいいのにという願望」です。 http://d.hatena.ne.jp/sekom/20111209 普段、品質やテストなどには興味なさそう（？）にしている私ですが、 たまには、エンジニア視点から、テストについて語ってみましょう。 xUnit成熟度モデルって？ xUnit成熟度モデルとは、 組織がxUnitをより適切に利用できるようになることを目的として 遵守するべき指針を体系化したものである。 あわせて読みたい : 能力成熟度モデル統合 (CMMI) - Wikipedia 正味の話で言うと、僕がJUn
TDD Boot Camp 横浜に参加してきた #tddbc - Diary of absj31
11月5日 TDD Boot Camp( #TDDBC )横浜 一般枠(神奈川県) 2011/11/05 TDD Boot Camp 横浜 #tddbc - Togetter TDD Boot Camp(TDDBC) - TDDBC横浜 (写真：ペアプロ＆レビュー時の1枚。) 関東圏では2011/10/08『TDDBC 東京 for c++』以来となるのTDD Boot Camp。しかも開催地が横浜(且つ家から超近い!!)という事で募集には即申込み。晴れて抽選に当たる事が出来たので、参加して来ました。 開催地はあーすぷらざ（神奈川県立地球市民かながわプラザ） ＠本郷台。京浜東北線/東海道線等の『大船駅』から程近い場所に位置するところになりますね。私からすると馴染み深い『ホーム』でしたが、多くの参加者の方からすると『アウェー』な地でもあったようです。(^.^;) 家からは距離にして約7km程
TDD BOOT CAMP 信州をいつかやってみたいと妄想 - @kotyのブログ
何で「長野」じゃなくて「信州」なんだ？という疑問もありますがあえて。 近頃開催されて盛り上がった模様のTDDBC 札幌2.0の主催者id:shuji_w6e さんが、スモールスタートによる地方開催をすすめられています。 TDD Boot Camp 札幌 2.0 開催しました！（運営編） 先に結論を言ってしまえば、地方でTDD Boot Campをやってみたいな、と思っている人がいるならば、まずは自分たちでコンパクトにやってみると本編で生きてきます。主催者の得意な言語を使って、テスト駆動開発について勉強しようというのをやってみるべきです。 ちなみに、今後の地方開催も多く予定されていますね。 前回のNSEGでid:tmtms さんが「TDDBCやってみたいですね」という話をしていたのですが、「やってみたいけどちょっとハードル高いなぁ。。。」と尻込みしているというのが正直なところでした。 「TD
TDDBC 札幌 2.0自己紹介スライド
8. _ | __ __ | _ ´ , .| | | || | ´ || | | || | - _~ )^),- | |_ __| , γ ) - || | _ @shuji_w6e ● ● | " ) __ __ " _ _ :j´ , j ~~| | | | |_ | | | | || / , || || Twitter | ||/ / r. || | ||| n | (⊆ .|_|_ _ _| _ (" |_| _| 10. , '´ ` i r- - -‐ i | |,, ,{| | " '` {" l Python .i ,__''_ ! i/ l . | ,. - / | /| |` - / . / -` -| l l . / ∨ l |! | > | i / | ^> . | | _,| | | |.|-< i / , _ __! .| {.| `- ,.--- ^! |
TDD Boot Camp 札幌 2.0 開催しました！（運営編） - やさしいデスマーチ
本日、札幌では４回目となる TDD Boot Camp 札幌 2.0 を開催され、 TDD界のリーダーであるid:t-wada氏に札幌で２回目の登壇をしていただきました。今回はTDDに関連する部分は、参加者のブログにお任せし、自分の方からは主催者視点でのレポートとしたいと思います。これを機会に他地域でのTDD Boot Campの開催の参考になったり、開催したいなと思って頂ければ幸いです。 開催まで 今回は札幌開催で４回目ということもあり、開催自体の準備は少なかったです。これは言い換えれば、はじめての時は色々と試行錯誤が必要ということでもあります。 参加人数の動向 札幌開催での参加人数は次のようになっています。 日付 No 参加者 備考 2010.12.18 0.5 ６名 Javaのみ 2011.1.23-24 1.0 ２６名 @t_wada氏登壇、言語自由（Java, Ruby, VB,
なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
テストコードのリファクタリング - 千里霧中
ユニットテストの再利用や継続的利用を行おうとすると、テストコードにも保守性等に優れた良い設計が求められるようになります。そこで出番が増えてくるのがテストコードのリファクタリングです。 ただ現状、テストコードのリファクタリングはいくつか課題を抱えています。今回はその課題の１つである「リファクタリング前後でテストコードの振る舞いが変わっていないかチェックするテスト」（以下リファクタリングの回帰テスト）の実現方法についてまとめます。 テストの回帰テスト まずリファクタリングの回帰テストを真っ当に考えていきます。テストコードをテスト対象としてみると、一般的に以下の特徴が見えてきます。 SetupメソッドやMockオブジェクト等を通して、テスティングフレームワークから間接入力を受けます。 Assertionメソッド等を通して、テスティングフレームワークに対して間接出力を行っています。またMockオブ
Joshua Kerievsky 氏講演会「リファクタリングの戦略と戦術」 - 科学と非科学の迷宮
概要 URL http://patterns-wg.fuka.info.waseda.ac.jp/JK2010.html 日時 2010/03/18 18:30 - 20:30 場所 国立情報学研究所（学術総合センター） 12階 会議室 twitterハッシュタグ #PWG_JK 講演タイトル Refactoring Strategies & Tactics 講演者 Joshua Kerievsky (Industrial Logic, Inc. and Cutter Consortium) 「パターン指向リファクタリング入門」の著者。 パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法 作者: ジョシュア・ケリーエブスキー,小黒直樹,村上歴,高橋一成,越智典子出版社/メーカー: 日経BP社発売日: 2005/08/04メディア: 単行本購入: 11人 クリック: 31
TDD Boot Camp のお題を C# と Git でやってみた - 予定は未定Blog版
自分で考えたお題を自分で解くとかそれなんてマッチポンプ・・・ 打ち上げ終了後のホテルと、翌日の帰りの新幹線の中で書いたコードを順番に追ってみます。 準備するものは Git で、あるといいものは Visual Studio 2010 と NUnit です。 まぁ、割と小さいコード (テストを含めても 300 行もない) だし C# を知らない人でもそれなりに雰囲気は掴めると思います。 あ、このエントリかなり長いです。 準備 Windows の場合、Git Bash を開いて、適当なフォルダに移動して git clone git://github.com/bleis-tift/MotsunabeZombieProject.git cd MotsunabeZombieProjectとしてください。 MotsunabeZombieProject というフォルダができて、その中に Git のリポジト
[コラム] システム時刻に依存するメソッドをテストする 3 + 1 通りの方法 - TDD.NET
ユニットテストの天敵は、 外部に依存しているプログラムです。 依存しているものからの応答によってプログラムの動作が変わるとすると、 ユニットテストが困難になります。 たとえば、 データベース、 あるいは何らかの通信など。 もっとも身近なのは、 システム時刻でしょう。 次のようなメソッドを作るとします。 現在時刻が午前だったら、 "Good morning!" と返す。 午後だったら、 "Hello!" と返す。 このメソッドのテストケースは、 どう書きましょうか? 製品コードは、 どのようにしたらいいでしょう? なにも工夫をしなければ、 1日に 1回しかテストが出来ないか、 PC の時計を変えてはテストを実行することになるでしょう。 何か工夫をして、 テスト実行時には PC の時計に依存しないようにする必要があります。 .NET Framework に用意されている DateTime.No
![[コラム] システム時刻に依存するメソッドをテストする 3 + 1 通りの方法 - TDD.NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/c50b1ca0898c13b4c2b9eaaf8b9adc0e9348ce3f/height=288;version=1;width=512/http%3A%2F%2Fbluewatersoft.cocolog-nifty.com%2F.shared-cocolog%2Fnifty_managed%2Fimages%2Fweb%2Fogp%2Fdefault.png)
レガシーコードをライブで扱う際のポイント試案
twitter で TDDBC Hokuriku (2010) のレガシーコード改善を Coding Dojo で行った際の Ruby チームは比較的うまくいってたけど、あれって○○な流れだっけ的な話をしているうちに気になってることをまとめておこうと思い立ったので、できるだけ書き出してみる。 何かのきっかけになれば嬉しい。 素材（レガシーコード）のポイントまず動くこと触ったことがあること1ある程度でいいので機能別に書かれていること オブジェクト指向であるとなお良い（使える技が増える）小規模であること ただし完全に単機能だと余地が少ないのでテストを足しにくい外部 API 依存しまくりの場合は単なるレガシーコード改善とはまた別なテクニックの習得に繋がってよいかも自動実行できるテストがないこと :-)1 については「えっ」て思うかもしれないけど、放置してるものは依存ライブラリの関係や、そもそも動
私家版テスト駆動開発 - rabbit2goのブログ
テスト駆動開発(TDD)をやってみたいけど最初の一歩がなかなか踏み出せないという人が少なくないようだ。あまり形式張らずに出来るところから少しずつでも挑んでいくのがコツだと思うのだけど、教科書に出てくる「正しいやり方」に躊躇してしまうケースがあるらしい。そんな訳で、今回は我流のテスト駆動開発方法を紹介してみたい。 テスト戦略を決める 制限のある開発期間内に効率的にテストコードを作る必要がある以上、何を目標として何処までをテストすべきか目標を決めておくことは欠かせない。もちろん、カバレッジ100%のコード作成は望ましいものの、異常系を含めてそこまでの網羅率を実現するのは難しいことが多いし、GUI処理は時間をかけてマクロを作るより人間が目視で確認した方が手っ取り早かったりする。費用対効果を考えて、もっとも効果の大きい箇所を重点的にテストコードでカバーすることを考えたい。 テストコードは後付け 由
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ファイルを保存した瞬間ユニットテストを実行 - Qiita
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
Comparing Moq to Rhino Mocks