タグ

TDDに関するuronim1のブックマーク (8)

  • テスト駆動開発導入時のよくある質問

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    テスト駆動開発導入時のよくある質問
    uronim1
    uronim1 2008/04/08
  • InfoQ: Cockburn氏テスティングを語る: 本物のプログラマにはガッツ(GUTs)がある

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    InfoQ: Cockburn氏テスティングを語る: 本物のプログラマにはガッツ(GUTs)がある
  • TDD/BDDは不完全なユニットテストを招くか?

    Peter Ritchie氏は、TDD(source)やBDD(source)にこだわることで、良いユニットテストを書かなくなる傾向があるのではないか、という懸念を表明した(source)。特に「インタラクションテスト(interaction testing)」というマントラは、不完全なユニットテスト、すなわち、どのような条件下で利用されても稼働するユニット(オブジェクト)である、という証明ができていないテストをもたらすと述べている。Peter氏の考えで最も興味深いのは、TDDとBDDのそもそもの意図に対する反対意見と受け取れるところだ。 Peter氏の根底にあるのは、クラスの概念は現実世界の概念とは独立した抽象化の仕組みだということだ。これに従えば、良いユニットテスト(source) とは こうした現実世界とは独立しているクラスを検証することである。この考えは、以下のように、TDDとBD

    TDD/BDDは不完全なユニットテストを招くか?
  • 第1回 連載を始めるにあたって | gihyo.jp

    ニコニコ動画:https://www.nicovideo.jp/watch/sm2195306 はじめまして、和田卓人(わだ たくと)といいます。 このたびgihyo.jpにて、テスト駆動開発(TDD)の連載をすることになりました。 筆者は『WEB+DB PRESS Vol.35』の特集1「実演! テスト駆動開発」と、『WEB+DB PRESS Vol.37』の特集1「実演! リファクタリング」を執筆させていただいた際に、同時に動画企画を行わせていただきました。おかげさまで「実演! テスト駆動開発」と「実演! リファクタリング」は、誌および特設サイトの企画として、たいへん多くの方にご覧いただき、多数のご意見をいただきました。頂いたご意見の中には、以下のような意見がありました。 もう少し初心者にもわかりやすく もっと突っ込んだ内容をもう少し詳しく もう少し実践的に 特集をお読みくださった方

    第1回 連載を始めるにあたって | gihyo.jp
    uronim1
    uronim1 2007/10/27
  • TddAntiPatterns - TDD のアンチパターン

    TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)

    uronim1
    uronim1 2007/07/08
  • BDDIntro - 生きてま2 改 - Trac - A NEW LOOK AT TEST-DRIVEN DEVELOPMENT

  • 「テストを最初に書くことのメリット」? - dann's blog

    http://d.hatena.ne.jp/thata/20050823#1124765700 僕が開発をする場合はインターフェースから書き出すことは最近はまずないです。インターフェースを検討するために実装から書き始めます。ある程度実装をして試行錯誤してみてから、インターフェースを書きます。 何故かと言うと、ラフスケッチがないと、当のインターフェースが見えてこないからです。 僕がTDDを試してみて思うのは、TDDでは試行錯誤の段階がないために、インターフェースの修正を初期段階で頻繁に繰り返すことになるのでロスが大きいということです。 だから、ラフスケッチにTDDは向いていないんじゃないかなと思っています。検討する度にassertionと実装を変更するのは速度が遅く、ラフスケッチには向かないと思っています。 TDDの感覚は、僕にはどうもいきなり番書いているような感じがしてどうもしっくりき

    「テストを最初に書くことのメリット」? - dann's blog
  • http://www.fastwave.gr.jp/diarysrv/arino/200508a.html

    uronim1
    uronim1 2005/08/11
  • 1