Visual Studioを使用したテスト駆動開発ブートキャンプ（TDDBC）に参加しました - redwarrior’s diary
2015/9/2にマイクロソフトセミナーを品川のマイクロソフト社で受けてきました。タイトルの通り、和田卓人（id:t-wada）さんは日本のTDD（テスト駆動開発）の第一人者であり、とても勉強になりました。 著名人の話を無料で聞けるとは、マイクロソフトセミナーはとてもお得だと思いました。マイクロソフトのセミナーなので、説明がC#で行われていて、その点も良かったです。 セミナーの流れ セミナーの全体の流れとしては、まず、和田さんがTDDについての講演をしばらく行い、その後、出された問題を解くことでTDDを実際に体験し、最後に問題について全員でコードレビューを行うという流れでした。TDDの体験では、二人一組になって、ペアプログラミングを行いながら問題を解きました。 講演 講演は、配布された資料を使って行われました。最初に自己紹介と流れの説明で、次からTDDの解説が始まりました。まず書籍アジャイ
2014-01-22
先週、TDD Boot Camp Tokyo for C++ 2014-01を講義、デモ、TA、運営を全て一人で開催させていただきました。 1人での開催は、私がすごいというわけではなくて、参加者6名という小規模な開催をしたからです。 事の発端は、レポート係として参加した「Agile Samurai Base Camp」になります。その打ち上げに参加した私は、TDDトラックを担当した講師の方々とお話しさせていただく機会に恵まれました。 その際の話のほとんどは、寝て起きた時に忘れてしまったのですが、一つだけ強力に頭の中に残っていたことがありました。 TDD Boot Camp は、東京で開催すると直ぐにキャンセル待ちになって、需要があるんだけど、なかなか開けないんだよねぇ。新しい人がどんどん開催してくれれば良いのに 実際のセリフは酒と共に飛んで行ってしまい違っていたかもしれませんが、このような
「テスト駆動開発における組み込みプログラミング」 - Yasuo's Notebook
先日、O'Reilly Japan - テスト駆動開発による組み込みプログラミングが発売されました。 本書では、アジャイルソフトウェア開発宣言の著者の一人であるJames W. Grenning氏が組み込みソフトウェア開発にフォーカスしたテスト駆動開発について詳細に解説しています。 組み込みソフトウェア開発では言語がC言語であることの他にプラットフォームや開発環境のバリエーションや制約が多いこともあって、なかなか他の言語でのテスト駆動開発のテクニックをそのまま使うことはできませんでした。 しかしながら、組み込みソフトウェア開発でのテスト駆動開発のノウハウのまとまった情報はなく、各自がそれぞれ工夫をしながら取り組む必要がありました。 私も2004年ごろからXPJUG関西の組み込みTDD分科会などで組み込みソフトウェア開発のやり方についてコミュニティで議論してきました。その活動の中で本書で紹介
テストと言うパートナー #TddAdventJp - 日々常々
TDD Advent Calendar jp: 2011の 12日目です。 前：あなたは写経しますか - pocketberserkerの爆走 次：TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組 テストはパートナー 「何を言ってるんだ？」な感じかもしれませんが、私にとってテストはパートナーです。 私がTDDのコンテキストで言う「テスト」はDeveloperTestです。このテストは開発者の開発者による開発者のためのテストであり、つまり開発者たる私のためのものです。私だけのためにテストは働いてくれます。 テストに対する不安 TDDや自動テストと言う言葉に触れ、「いざテストを書こう」と思った時。もしくはよく知らないままテストコードを書かなければならなくなった時。テストに対して不安を感じると思います。TDDは「不安をテストにする」とか言いますが、そもそもテス
右手に感情、左手に数値 - カバレッジを味方にしよう - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar 2011 の 7 日目の参加エントリです。前日は @sue445 さんの実録！TDD風景でした。 しかし TDD Advent Calendar 2011 は、名エントリが多いですね……ハードルが上がり続けていて胃に穴があきそうです。私の言いたいことの多くは、既に @bleis さんのTDD の基礎体力と、TDD に対する想いや、 @shuji_w6e さんのTDDを学ぶべき10の理由で語られています。二つとも素晴らしいエントリなので、ぜひ読んでみてください。 そろそろカバレッジについて一言いっておくか さて、今日書くのは、カバレッジについてです。 @bleis さんのエントリに以下のような記述があります。 もう一度言いますが、TDD のテストは Developer Testing であって、品質保証を目的としたテストではありません
xUTP Magazine - ぺけま
xUTP Magazine について 『xUTP Magazine』、略して『ぺけま』は、xUTP読書会の有志による xUnitester の xUnitester による、xUnitester とそうでない人のためのウェブ雑誌です。 最新号 0004号 巻頭言 xUTP Topics: 第三回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」 TDD Live 番外編(TDD序破Q) 編集後記 バックナンバー 0003号 xUnitester Hotlinks: 第一回 和田卓人さん(下) goos 読書会への誘い 来年(2012年)のTDDBC予報 0002号 xUnitester Hotlinks: 第一回 和田卓人さん(上) xUTP Topics: 第二回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」 mockitoでサ
TDD Boot Camp 札幌 2.2 を開催します #tddbc - やさしいデスマーチ
2週間ほど前にTDD Boot Camp 札幌 2.1が開催されたばかりですが、11/3にTDD Boot Camp 札幌 2.2を開催します。 ATNDの開催概要にも記載していますが、札幌では6回目のTDDBCとなります。TDDBCは、テスト駆動開発の体験のためのイベントです。しかし、実戦で使えるためには反復的な練習と、レガシーコード改善や受入テスト駆動開発など、TDDから１歩前に進んだテーマも必要であり、TDDBC札幌では様々なアプローチをしてきたと思います。前回の2.1では参加者も皆TDDに慣れ始めたと感じました。 そこで、1回基本に返る事をテーマとしてTDDBC札幌2.2を開催したいと考えています。これまでのTDDBCに参加した人であれば、これまでの成果を試す場所、初めてのTDDBCであれば経験者と一緒に体験できる場所、というのが目標です。お題もあえて、1.0の時に使用したものを使
モックによるインターフェイスの発見 - Digital Romanticism
設計ツールとしてのモックの使い方について考える。 導入 先日、"Mock Roles, not Objects"の日本語版「ロールをモックせよ」を公開しました。この論文は2004年に書かれたもので、著者はSteve Freeman氏、Nat Pryce氏、Tim Mackinnon氏、Joe Walnes氏という豪華メンバーです。また、Steve Freeman氏とNat Pryce氏は『Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))』（いわゆるGOOS）の著者でもあり、"Mock Roles, not Object"で語られている思想はGOOSのベースになっているとも言えます。 今回は、この"Mock Roles, not Objects"（以下、MRnO
TDDBC 札幌 2.1 開催しました - やさしいデスマーチ
シルバーウィークの後半に札幌にてTDD（テスト駆動開発）の体験型イベントであるTDDBC（札幌版）を開催しました。 TDDBC 札幌 2.1 であること ナンバリングが変な事になっていますが、札幌では今回で通算５回目の開催になります。近年、テスト駆動開発は開発手法として非常に重要なスキルの１つと考えられていますが、なかなか開発現場で実戦する機会はありません。自分で学習していくことも可能ですが、見よう見まねで学習するよりも同じような志*1を持っている人が集まって、同じ目標に向けて学ぶ方が効率が良いものです。1人で悩むよりもみんなで悩み、解決できるような人がイベントにいると安心ですから。 TDDBCは、テスト駆動開発を実際にやってみるためのイベントです。TDDの伝道師である id:t-wadaさんが講師を務め、午前中に座学、午後に演習というのが基本スタイルとなっています。しかし、TDDやアジャ
TDDBCでの教えを胸に、巨大なC#レガシーコードと戦ってみた - hachiNote
目的 業務で現在、とても厄介なC#コードと戦っています。途方に暮れかけていましたが、TDDBC札幌で教えていただいたことから突破口が見えてきました。感謝の気持ちを表しつつ、ちょっとした現状メモです（それにしてはすごく長くてすみません）。 正確には「戦ってみた」じゃなくて、「戦い始めた」ですね。 敵のデータ どんなアプリケーションか C#で書かれた（一部C++もあるが）Windowsフォームアプリケーション。ドライバ的なところからビューアまで、かなり巨大。 とりあえず今自分が見ているところはビューアの改造とかのわりと表層的な部分。C#のみ Visual Studio 2008 Professional Edtionで開発 コードの状態 コードの質が悪すぎる。今までみたコードの中で最もひどい コピペコード多すぎ。とにかくところかまわずがんがんコピペ状態。 メソッド長過ぎ。クラスがでかすぎ。Cじ
[NEWS] Visual Studio と NUnit が統合される - TDD.NET
それぞれの次期バージョンで、 親和性を高める計画が公表されています。 NUnit のファンも 単体の NUnit ランナーを見なくなる日が来るのかもしれません。 まず NUnit から。 近々 NUnit 3 にバージョンアップする予定になっていますが、 そのアーキテクチャ計画書 "NUnit 3.0 Architecture" (英文; 2011/02/19付け) を見ると、 IDE 統合の記述があります。 In the area of IDE integration, we will deliver a Visual Studio addin or package for running NUnit tests. ( IDE 統合の分野では、 NUnit のテストを実行するための Visual Studio のアドイン(またはパッケージ) を提供します。 ) 一方、 Visual St
![[NEWS] Visual Studio と NUnit が統合される - TDD.NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/bce7b4032f661a7a26d25348e039d8b1c32b9de1/height=288;version=1;width=512/http%3A%2F%2Fwww.tdd-net.jp%2Fimages%2F2011%2F07%2F11%2F20110711_vnext_unittestexplorer.png)
TDDBC 東京 1.6でサポートスタッフをやってきました
TDD Boot Camp 東京 1.6にRubyのサポートスタッフとして参加してきた。 当初の予定ではあくまでサポートなのでペアプロには参加しない予定だったけど、Rubyのグループが5人で人数が奇数になってしまったので急遽ペアプロに参加することにした。 この辺は@t_wadaさんや主催の@pocketberserkerさんとも相談してペアとトリオのふたつに分けるっていう話もあったけれど、僕が「せっかくだからペアプロして帰ってもらいたい」と思ったので若干の迷いはあれどペアプロに参加することにしたのでした。Ruby組は@takahashimさんや@1syoさん、@kwappaさんたちが参加されていて彼らなら付きっ切りでサポートしなくても大丈夫そうというのも理由のひとつ。 コードレビューを見た感じだと一応はうまくいったんじゃないかなと思う。特に@1syoさんと@takahashimさんのペア(
『TDD信者が増えてきてるのでこの辺で一言言っとくか。』
令和からの働き方について -TownSoft- 元「傲慢SE日記」で、しばらく放置していました。 2020年からはこれからの働き方などについて書いて行こうかと思います。 TDDは良いか？ とりあえず、過去に色々TDDについて記事を書きましたのでそれを掲載します。 仕事が出来ない人ほど横柄なのは何故？（2007年05月12日） リファクタリング、テスト、開発速度など（2007年08月01日） テストファースト（2007年08月21日） まぁ、この中で一番参考になるのは最後に書いたテストファーストかな。今の僕の考えと合わせると心情が良く分かる。 TDDはプログラムを書く前に仕様の詳細まで把握する事が出来て、なおかつテストコードまで作ってくれる優れものだ。しかし、局面によってはTDDは不要になる。僕も数年前はTDDやテストファーストを実践していた。効率的だと思った所もあるが、大体はマンネリに陥っ
makeをファイル更新のトリガで自動実行
今日は、makeを使ってTDDするときに、 コード変更 いちいちmake -> エンター（ﾀｰﾝ ビンゴだ！） ってやるのが、結構めんどくさく感じてまして。 求めてる動きは、ソース変更したら、勝手に結果でねぇかな と思ってたんですよね。 で、今まさに 開発言語 C++ Cygwinで開発中 GoogleTest と GoogleMock で、結局シェルスクリプトで実現することにしました。（いろんなアドバイスもらったので、それに関しては後述します） まずシェルスクリプトです #!/bin/sh echo "check file update!" makeOpt=$1 # 作業ディレクトリ（衝突しない名前に） workDir=autorun rm -rf $workDir mkdir -p $workDir while [ 1 -eq 1 ] do isMake=0 # 更新確認するファイルを
デフォルトでテスト成功にするという JUnit の設計判断とその功罪について
きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm @t_wada デフォルトで成功には違和感を覚えますね。。。故にIDEのJUnit自動生成ではスケルトンコードで失敗するようになっているんでしょうけど。一番怖いのがリファクタリング時にもし何かassertを消してしまった場合にも成功するというのが。 2011-05-22 16:05:24 Takuto Wada @t_wada @kyon_mm リファクタリングで assertion を消すことがあるかは疑問ですが、デフォルト成功というところには予想以上に多くの初心者が足を取られているようですね。 2011-05-22 16:11:01
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自分のコミュニティを始めてみませんか？
Google Sites: Sign-in
Driving Quality with TDD
Sustainable TDD
zusaar.com