【翻訳】テスト駆動開発の定義 - t-wadaのブログ
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
自動テストはなぜあまり書かれてこなかったのか 和田卓人×倉見洋輔×古川陽介がひもとく、フロントエンドテストの歴史
セッションテーマはフロントエンド開発テストの「必要性」と「歴史」 古川陽介氏（以下、古川）：さて、次のパネルディスカッションは、「フロントエンド開発テスト最前線」というタイトルで発表していこうかなと思います。 ご登壇いただくのは、タワーズ・クエスト株式会社取締役社長の和田卓人さんです。和田卓人さんはリクルートの技術開発の技術顧問をやっています。 また、株式会社リクルート兼株式会社ニジボックスの倉見洋輔さんもお呼びして、今回は話をしていこうかなと思います。倉見さんに関して言うと、どちらも私の直属のメンバーというかたちで、一緒に働いています。 今、プロダクト開発において、やはりテストというのが開発の生産性などを決める上でもかなり重要な要素になっているかなと思っています。この必要性や歴史を3人で話していけるといいなと思っています。 テスト駆動開発の第一人者・和田卓人氏 古川：じゃあ、もう始めてい
過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
「自動テストとテスト駆動開発、その全体像」を執筆しました（Software Design 2022年3月号） - t-wadaのブログ
【更新】寄稿した記事が Web に公開されました 技術評論社様のご厚意により、 Software Design 2022年3月号に寄稿した「自動テストとテスト駆動開発、その全体像」が gihyo.jp にて公開されました。誠にありがとうございます！ gihyo.jp はじめに 2022年2月18日発売の Software Design 2022年3月号 にて、第2特集「そろそろはじめるテスト駆動開発」の第1章「自動テストとテスト駆動開発、その全体像」を執筆いたしました。第1章では、混同されることの多い自動テスト関係の概念を自動テスト、テストファースト、テスト駆動開発（TDD: Test-Driven Development）の3つの段階に分け、それぞれの効果や注意点を包括的に整理整頓しています。 ソフトウェアデザイン 2022年3月号 作者:大竹 章裕,瀬戸口 聡,庄司 勝哉,光成 滋生,
TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング
本編開始は 19:05 からです こちらのイベントのYoutubeLive配信のアーカイブです https://tddbc.connpass.com/event/183044/ チャプター 0:00:00 準備開始 0:19:05 講演開始 0:41:55 ライブコーディング開始 0:57:20 プログラミング開始 1:02:00 最初の RED ？ 1:19:00 fake it 1:26:50 最初のリファクタリングおわり 1:36:40 質問タイム 1:51:20 5の倍数に着手 1:53:40 前半のデモのまとめ 1:55:20 質問タイム2回目 1:56:45 リリースから3年後の世界（テストをメンテナンスしやすくする） 2:14:20 テストの構造化とリファクタリングの説明
プライベートメソッドのテストは書かないもの？ - t-wadaのブログ
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
TDDはゆるく実践しても大丈夫 - 千里霧中
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
設計だけでコードを書けないなら断る、TDD伝道師の原点
コンピュータに最初に触れたのは、中学1年のときに家にパソコンが来たことでした。父親がコンピュータソフトウエア開発の会社を立ち上げて、家に開発用のDOS/Vパソコンがやって来たのです。 悔しいことに、その時点ではプログラミングにはあまり興味を持ちませんでした。単なるゲーム機の一種としてDOS/VやWindows 3.1のパソコンに触れていたというのが実情です。高校まではプログラミングは全くやっていませんでした。 世の有名なプログラマーは、たいてい小さい頃から街頭でパソコンを触っていたりマイコン雑誌を読んだりしています。それに比べると、コンピュータにあまり興味を持たなかったことにコンプレックスや一種の後ろめたさを感じています。 留学でコンピュータの重要性に気づく 1996年に国際基督教大学（ICU）に入りました。ICUには教養学部（リベラルアーツ）という一つの学部しかありません。「最初の2年間
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」 僕のコメント「書いていません！」 僕のコメント「書きました！」 僕の主張 本記事は僕の実験結果（経過報告）であり、
テストカバレッジ - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/TestCoverage.html 「テストカバレッジ(コードカバレッジ)の目標値はどれくらいがいいのか？」という質問とか、コードカバレッジの高さの自慢とかを、ときどき耳にする。でも、大事なポイントを外している。コードカバレッジは、コードのテストされていない部分を発見するための有用なツールである。ただテスト自体がどれだけ良いかという指標としては、テストカバレッジはほとんど役に立たない。 二つ目の例を先に検討してみよう。「カバレッジが87%以上じゃないと本番には入れない」というようなことをやっているところも多いみたいだ。「TDDやっているならカバレッジが100%があたりまえ」という言葉を聞くこともある。賢人が言った: カバレッジが高いことを期待する。マネージャがそう期待することもある。でも微妙な違いがある。 – Brian Mari
開発現場で保守性の高いTDD／BDDを実現するための3つのポイント――テストレベル／網羅性とは
開発現場で保守性の高いTDD／BDDを実現するための3つのポイント――テストレベル／網羅性とは：いまさら聞けないTDD/BDD超入門（4）（1/3 ページ） 連載目次 前回の『TDD／BDDにおける「振る舞い』の意味するところとは何なのか」までで述べたような、TDD／BDDを導入するときには、現場で「で、今までやってきた単体テストと結合テストって、どうやってこれに組み込めばいいんだっけ？」「網羅的なテストをどうやって書けばいいんだろうか？」「テストを先に書くだけくらいにしか違いがないのではないだろうか？」などの疑問が出てきます。 今回は、これらの導入時の疑問を解決するようなパターンを紹介します。まずは説明のためにいくつかの言葉の定義を紹介してから、どういったことで保守性の高いTDD／BDDを実現できるかを紹介します。 テストレベルの定義 大まかに言えば、「テストレベル」とはテスト対象の大き
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
TDD の Death and Rebirth まごころを君に - @ledsun blog
我が輩のTDD体験を語る 背景 ここ最近のTDDに関する話の噛み合なさっぷりよ・・・ TDDは死んだ。テスティングよ栄えよ。 by DHH 【翻訳】TDD is Fun 【TDDを再定義したほうがいいって話だったのさ】UncleBob, Martinfowler, DHHのツイートまとめ TDDという名の幻想... 大きな疑問 業務でxUnit使ったテストファーストやってる人はいるの？ TDDは死んでないと言うても、業務でxUnit使ったテストファーストやってる人はいるの？ じゃあ、自分はどうなのか？自分語りをする。 前提 ここで話すTDD xUnitを使ったテストファースト 今回はそれ以外を話さない XPの第一版にはそれ以外の要素は書いてなかった。 俺はそう刷り込まれた。 一番大事だと思う要素から話す。 「これからインスピレーションを得たもっといい方法があるよ」って話は喜んで聞きます。
【翻訳】TDD is Fun - diskogs's diary
@solnicが、DHHの例の記事へのカウンター的な記事をポストしてまして、自分のために読んでみたらよい内容だと思ったので、翻訳してみました。翻訳ミスとかあると思いますが、、、すみませんです。。。 TDD is Fun Posted by solnic on Apr 23 2014 著 solnic 2014年4月23日 Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that
テスト自動化研究会 - 4時間で学ぶ、効率的な自動テストスクリプトのメンテナンス
オープンソースのブラウザテストツール「Selenium WebDriver」の使い方と、テストスクリプトを効率よくメンテナンスする方法について、実際にプログラムを書きながら学べるチュートリアル形式教材です。 前半は、Selenium入門ドリルです。基礎から丁寧に解説されているので、Seleniumは初めての方でもテストが書けるようになります。 後半では、テストのメンテナンス効率をあげるための技法「ページオブジェクトデザインパターン」の習得を目指します。こちらも基礎から解説していくので、Seleniumが初めての方でも大丈夫です。 プログラミング言語Javaでテストスクリプトを作成するので、Javaで基本的なプログラムが書ける必要があります。 自習教材として利用する場合 前提知識・事前準備手順ドキュメントの手順に従い、必要な事前準備とインストールを完了させます。作成したEclipseプロジェ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルサムライの次に読む技術書
自動テストの誤解とアンチパターン in 楽天 Tech Talk
TDD のこころ @ OSH2014
