Agile Samurai Basecamp in Tokyo <2> - The first cry of Atom
This entry follows previous post. The practical methods about TDD are explained in this section. And also, it is written as an article of TDD advent calendar on 10th day. How to start TDD? Takuto Wada(twada) The right wing of agile is what about team environment, management, scrum, iteration and standup meeting. On the other hand, the left wing of agile is not perceived enough to ordinary people.
札幌Ruby会議01で発表させていただきました - t-wada の日記（旧）
本日は Regional RubyKaigi の第二弾となる、札幌Ruby会議01で発表させていただきました。会場および ust でお聞きくださった皆様、ありがとうございました。 東京の時は 30 分ありましたが、今回は LT です。5分間の中に言いたいことを凝縮しました。 タイトルは 「そろそろカバレッジについて一言いっておくか」 LT ということもありますが、やや釣り気味ですね。 本気のタイトルはどうだろう…「右手に感情、左手に数値」か「道具を知り、考えを知る」でしょうか。 発表の内容はテストとリファクタリング、カバレッジについてのことで、Ruby 独自の内容はほとんどありません。 資料を slideshare に上げておきました。講演の動画は例によって近いうちにニコニコ動画に上がると思います。 Sapporo RubyKaigi01 twada LTView SlideShare p
Mistaeks I Hav Made: Allowing tests to drive development
Good judgement is the result of experience ... Experience is the result of bad judgement. — Fred Brooks I have noticed teams who are new to TDD reach for ever more sophisticated tools to help them test their code rather than refactor their code to make it more testable. By doing so, they lose one of the major benefits of TDD: the feedback it gives on internal design quality. Code is difficult to t
J2EE勉強会での発表資料を公開します - t-wadaの日記
id:takubonさんからいただいたコメントに触発されてちょっと書いてみます。 リリースを行う際に利用者に公開したインターフェイスが「公布済みインターフェイス(published interface)」になります。短い期間のイテレーションを繰り返してチーム間で結合を繰り返していく場合には、利用者は他のチームとなります。イテレーションの期間に応じて不完全な形でインターフェイスを公布する機会があるかもしれませんし、実際に機能を制限してリリースを行ったりもします。 短い期間で反復開発しているということは、インターフェイスを公布する機会が増えるということです。公布する機会が増えれば、リファクタリングの範囲が公布済みインターフェイスに引っかかる確率も増えます。すると、公布済みインターフェイスの変更はリファクタリングの枠を越えて「仕様変更」となってしまうことが多くなってしまいます。 これがイテレーシ
リファクタリングするうちに仕様が見えてくる - 18 til i die (another phase)
私は，実際にテストとしてメンテナンスしていく価値を持っているのは，この大きいテストケースのほうだと考えています。この大きいテストケースをグリーンにするために，小さいテストケースのレッド，グリーン，レッド，グリーンの繰り返しがあったと考えるのです。 コードを書いて、リファクタリングしていくうちに、そのコード片に何をさせたかったのかがだんだん見えてくるということがありますが。 テスト駆動で開発していると、テストを通してだんだん仕様が固まってきて、その仕様に粒度の小さいテストが合わなくなってくる、ということなのかなあ、と思いました。 今やっている仕事はまさにそんな感じで進めていて、リファクタリングしていく中で、同じような仕事をさせるクラスのインターフェイスがDuck Typing的にだんだん揃ってきたり、そこに自分のコードを書く能力や知識の向上みたいな要素も絡んでソースコードがだんだんいい感じに
リファクタリングとテストの関係 - jun-ichi.blog.hatena
t-wadaさんのリファクタリングとテストの関係では、テストとリファクタリング、TDDの考え方が分かりやすく説明されている。 「動作する」を満たしてから、「きれいな」にとりかかる Red, Green, Refactor Red, Green, Commit, Refactor, Green, Commit リファクタリングとテストの関係 http://www.ne.jp/asahi/t/wada/articles/Refactoring_and_Test.pdf そのほか印象に残ったスライドを引用： テストの目的に戻ろう 何のためにテストするのか 誰のためにテストをするのか テストで何を知りたいのか リファクタリングとテストの関係 テストをロールによって分類する Developer(Programmer) Test 開発者が行う、開発促進のためのテスト 単体、ユニット、結合 …などなど
Martin Fowler's Bliki in Japanese - 進化的設計
Bill Venners: 「設計の終焉?」の中で計画的設計について述べられていますよね。計画的設計とはどういったものでしょうか？ Martin Fowler: 私は計画的設計と進化的設計とを区別しています。計画的設計とは、ソフトウェアを作る際にまず設計を行い、それからコーディングするようなことを指します。計画的設計はUMLダイアグラムの形をとることがあります。システムをサブシステムに分解し、サブシステム間のインターフェイスを定義するものだといえるかもしれません。計画的設計を用いれば、設計とコーディングとの間に明確な「スイッチ」が存在することになります。それぞれのタスクは普通、別々の人間が行います。設計者が設計を行い、開発者がコーディングを行うのです。必ずしも完全に確定したものではないにせよ、設計はほぼ確定したものとして扱われます。設計が優れていれば、コーディング時の変更が少なくなると言っ
リファクタリングとTDD - ひがやすを技術ブログ
リファクタリングは、あまりリファクタリングのことを知らない他人もしくは過去の自分が書いたコードが健全になるように修正するもので、今自分が書いてるコードのためのものじゃないと個人的には思います。 自分でコードを書いているんだったら、最初からリファクタリング不要なコードを書けばいいからです。人は、コードを書いたそばから忘れていくものですから、コードを書いているときが一番コードについて分かっているはずです。後から思いつくことも当然あると思いますが、そのようなケースはそれほど無いんじゃないでしょうか。 もし、後から思いつくことが多いとしたら、最初にコードの意味を理解して書いていないためではないでしょうか。 テストを書けば、書いたコードの意味を確かめることができます。コードの意味を理解していれば、最初からリファクタリング不要なコードを書けるのではないかと思います。 私が後からコードを変えることがある
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社 Aiming 近藤 宇智朗さんからの問題│CodeIQ
テストをプロダクトコードと別言語で書くことに関するTL
O'Reilly Media - Technology and Business Training
Refactoring Tests (or: How I Learned to Stop Worrying and Love the Red Bar)
http://stevef.truemesh.com/archives/000527.html
Casinonic Australia – how to get much pleasure?
artima - Refactoring with Martin Fowler
http://log.giantech.jp/837