和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09Mikiya Okuno
PHPでTDD&CIワークショップ、Jenkins + PHP の各種プラグインパート資料 - Yamashiro0217の日記
はじめに この資料は「PHPでTDD&CIワークショップ」 http://atnd.org/events/16626 で @yamashiro が発表するための資料だよ。 ワークショップ参加者じゃなくても記事読むだけで完結するようには書いてあるよ。 概要としては、Jenkins を使って PHP のウンコレガシーなコードをいかに綺麗にして行くかということを説明する。 自画自賛だけど PHPMD とか PHPCPD の使い方の説明の資料としてもそこそこイケてる資料になってると思いました。まる。 この記事に書かれてることは、割とTemplate for Jenkins Jobs for PHP Projectsとかぶってるけど、プラグインを絞ってあるのと、一個一個のプラグインについて解説、また実際にエラーが起きたときにどうすればいいのか書くよ。 Java と Jenkins のインストールとJ
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)
TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
By David Heinemeier Hansson on April 23, 2014 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happen
最小限の設定のTDD手法を使い、「何をテストすべきか？」から、よくある落とし穴の避け方まで、Reactコンポーネントをテストする方法を学びましょう。 導入 まず、 React を触ったことがあり、更にはいくつかのテストも書いた経験があるとしましょう。それでも、コンポーネントをどうテストするのが最善なのか、よく分からないかもしれません。どこから始めるのでしょう。具体的には何をテストすればよいのでしょうか。 いくつかのReactコンポーネントは簡潔過ぎて、そもそもテストが必要なのかすらはっきりしません。 AngularからReactに乗り換えた 人なら、テストには愛憎のような思いがあるかもしれません。 確かに Angular にはテストを支援するツールがたくさんありますが、同時にテストを書くのが難しくなる可能性があります。冗長ながら省略できない定型コードが多々ある上、 $digest の呼び出
コンピュータに最初に触れたのは、中学1年のときに家にパソコンが来たことでした。父親がコンピュータソフトウエア開発の会社を立ち上げて、家に開発用のDOS/Vパソコンがやって来たのです。 悔しいことに、その時点ではプログラミングにはあまり興味を持ちませんでした。単なるゲーム機の一種としてDOS/VやWindows 3.1のパソコンに触れていたというのが実情です。高校まではプログラミングは全くやっていませんでした。 世の有名なプログラマーは、たいてい小さい頃から街頭でパソコンを触っていたりマイコン雑誌を読んだりしています。それに比べると、コンピュータにあまり興味を持たなかったことにコンプレックスや一種の後ろめたさを感じています。 留学でコンピュータの重要性に気づく 1996年に国際基督教大学（ICU）に入りました。ICUには教養学部（リベラルアーツ）という一つの学部しかありません。「最初の2年間
Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo
テスト駆動開発の過去・現在・未来 / History of TDD - XPJUG 2018 Keynote
テスト駆動開発の過去・現在・未来 XP祭り2018 基調講演 2018/09/08 http://xpjug.com/xp2018-session-keynote/
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来についてshinjiigarashi
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
本編開始は 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 テストの構造化とリファクタリングの説明
2014-10-17 TDDを諦めることと、RSpecをやめること Ruby on Rails Ruby RSpec 開発手法 最近Web上でも仕事場でも、RSpecをやめて別のテストフレームワークに変えようと思っている……みたいな話をちょくちょく見聞きするようになった。僕がRuby on Railsで開発を始めた2012年8月当時、すでにRSpecはテストフレームワークのデファクトと言ってよかった。一斉を風靡したRSpecが、なぜ今見直され始めているのか。 きっかけになったのは今年4月の、Rails作者であるDavid Heinemeier Hansson(以下DHH)によるTDD is dead発言だと思う。 5月にはこの発言によるTDDへの風評被害を重く見たKent Beck*1が、レフリーにMartin Fowler*2を迎え、DHHと相対するドリームマッチが開催された。この会談の
ペアプロ・TDDの『お題』をまとめてみた #tddbc #coderetreat #pp_con - Diary of absj31
TDD及びペアプロを通じてプログラミングスキルを上げるべく、ネットで公開されている『お題』について色々情報収集してみました。 お題やテーマについては、見つけ次第随時追加していきます。 Stackユーティリティ from 『車窓からのTDD』 - 車窓からのTDD こちらについては自分でも試しに写経してみました。以下エントリ。 『車窓からのTDD』を写経してみた ( JDK7 / Eclipse4.2 / Quick JUnit / Mercurial / Bitbucket ) - Shinya’s Daily Report FizzBuzz問題 from TDDBC TDDBC お題 うるう年問題 from TDDBC TDDBC お題 LRU Cache from TDDBC TDDBC お題 ワードフィルタ from TDDBC TDDBC お題 以上、ここまでの4つのお題は和田卓人
「偉大な書籍は偉大な出だしで始まる。ケント・ベック著『テスト駆動開発』(2003, 2017)はこう始まります。 「動作するきれいなコード」。Ron Jeffriesのこの簡潔な言葉が、テスト駆動開発(TDD)のゴールだ。 」 テスト駆動開発エバンジェリストとして活躍している、和田卓人さん(t_wada)の講演より引用 セミナー講師やアジャイルコーチの立場で、私もTDDを教えることがよくあります。そんなときはこの言葉を意識しつつ、TDDはあくまでスキル、手法のひとつに過ぎず、本当に求めるべきは動作するきれいなコードなのだと、伝えるようにしています。そのことを説明する補助として、こんな図を作りました。 絵を描いてみて気づいたのですが、「動作する(Works)」には2つの側面があります。書いたコードが、書いたつもりの通りに動くこと(Verification)と、期待に応えて働き実際に役立つこと
TDDという名の幻想... - Qiita
TDDは死んだ。テスティングよ栄えよ。 by DHH http://d.hatena.ne.jp/yach/20140424#p1 【翻訳】TDD is Fun http://diskogs.hatenablog.com/entry/2014/04/25/085112 を読んで思ったことをつらつらと書いてみます。 TDDはできれば、やったほうが良いのは確か？です。 しかし、実際の開発現場で全面的に採用するのは ミドルウェア等の画面の存在しないソフトの開発以外では ほとんどの場合、無益です。 なぜなら、TDDを採用すると開発時間が膨らむ、すなわち、開発コストが 膨らむからです。そして、ソフト開発では細かな仕様は変化していきます、 するとTDDではそれに合わせ、テストを修正していかなくてはなりません。 また、TDDで書かれたテストが全てのケースを抜けなく網羅できていること は稀です、抜けは必ず
私はフロントエンドエンジニアとして働いてはいるのですが、巡り合わせが悪いのでしょうか？まともなテストを書いたことがないんですよね。まあ、それもでテストくらい書けないとなぁ。なんて思ってはちょいちょい調べたりする日々を過ごしていました。 そんなある日、たまたま TDD（テスト駆動開発） についての動画を視聴してみました。 TDD 自体は知ってはいて、なんとなく知っているくらいの知識ではありましたが、分かりやすい説明とその思想が好きで、のめり込むように見てしまいました。 その後も何度か視聴して、フロントエンドでも TDD したいなと考え始めました。 普段テストすら書いていないのにいきなり TDD とも思わないこともなかったですが、実際に普段自分がさわっているようなコードに落とし込んで書いていくと、テストする本当の意味というものが、より正確に理解できてきたような気がします。 そんなテスト初心者の
この記事は リクルートライフスタイル Advent Calendar 2018 8日目の記事です。 2018/12/10更新：続編で フロントエンドでTDDを実践する（react-testing-libraryを使った実践編）を書きました。 はじめに 自分のフロントエンドチームでは、TDDでの開発フローを実施することでフロントエンド開発の課題に向き合っていきます。 今回は、一般的に難しいとされるフロントエンドでのテストについて、どんな方針でテストを書けばいいかについて書いてみたいと思います。 フロントエンド開発の課題 プロジェクトによりますが、テストに関連するものでは以下のようなものが挙げられます。 実装する仕様について、プロジェクト内でどう認識合わせするか？ 開発工程のリライアビリティをどう担保するか？ テストの精度、粒度をどう考えるか？（クロスブラウザ、ユーザーの操作等の副作用、コスト
書評：GitHub Copilot とのペアプロ TDD でつくるローグライク RPG - 若くない何かの悩み
本記事は「GitHub Copilot とのペアプロ TDD でつくるローグライク RPG」の書評です。題名にローグライクRPGとあるのでゲーム開発の本なのかなと思ってしまいますが、本題は仕様の端的な表現をもたないシステムを LLM を使って真っ当に開発する方法の解説だと思います。タイトルにローグライクRPGと書いていることでゲーム開発に興味のない人の興味を失わせてしまい損をしている気がします。 背景 最近の LLM の流行を受けて私も Chat-GPT や GitHub Copilot といった LLM を開発で利用しています。端的に仕様を表現できるシステムは LLM に質問して実装を得る方が自分で実装するより圧倒的に速く正確であるという感想を抱いています。ただ端的に仕様を表現できるシステムばかりではありません。えてして価値を生んでいるシステムというのは端的な仕様の表現が存在しないもので
「愛せないコードを書くには人生はあまりにも短い」というタイトルで TDD について講演させていただきました #TddAdventJp #devlove2012 - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar jp: 2012 の 17 日目の参加エントリです。前日のエントリは [twitter:@shuji_w6e] さんの「軽量なテスト駆動開発を目指して」でした。 久しぶりのエントリです。久しぶりどころか、なんと日記の更新が一年ぶりになってしまいました……(もはや年記ですね)。 昨日、二日間開催された DevLOVE 2012 の二日目最後の(?)講演として、「愛せないコードを書くには人生はあまりにも短い」というタイトルで TDD について講演をさせて頂きました。 DevLOVE では何度か登壇の機会を頂いているのですが、昨日はいつもとは少しだけ違いました。その違いとは「イベントで私以外にも TDD の事を講演する人が複数いる」ということでした。諸橋さん([twitter:@moro])の「テストに開発をもっと駆動させたい」と和智さん
こんにちは、だんだんブログ勘を取り戻していきたい和田です。このエントリは TDD Advent Calendar 2013 の 11 日目のエントリです。このエントリでは、最近行ったテスト駆動開発関連の講演や寄稿に関して、この機会にまとめておきたいと思います。 DevLOVE 現場甲子園 まず 11/9 にDevLOVE現場甲子園2013にて「テストを書く文化を育てる戦略と戦術」というタイトルで短い講演をさせて頂きました。DevLOVE 甲子園は楽天第2タワー大広間の四隅で最大四つの講演が同時に行われるという意欲的なイベントで、話す方も気合い(と声量)が必要な場でした。 この講演では、開発者が自動テストを書く文化が無かった組織に自動テストの文化を育てる際の姿勢、心がけについて短い時間でまとめました。そのときの講演資料がこちらです(ライセンスは CC BY です)。 テストを書く文化を育てる
@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
かなり香ばしいタイトルですが、TDD Advent Calendar jp: 2011のエントリーとなります。前日の@bleisさんのエントリーの次になります。 はじめに TDD（テスト駆動開発）とは、「テストファーストを原則とし、テストが成功するようにプロダクションコードを書くというサイクルを繰り返す開発手法」です。XPのプラクティスの１つとして10年近く前に紹介され、ここ数年で再び１つのムーブメントとなっています。これは、TDD Boot CampがTDDへの敷居を下げ、体験する機会を提供した事も１つの大きな要因でしょう。 自分もTDDに魅せられたエンジニアの１人です。ぶっちゃけ、TDD信者とかTDD厨とか言われても可笑しくはありませんし、むしろ嬉しいくらいです。一方で、TDDを嫌う人もいるのも事実です。しかし、自分もTDDを銀の弾丸とは思っていませんし、適用しにくい領域もある事も理解
JJUG CCC 2014 fall 「私がTDD出来ないのはどう考えてもお前らが悪い！」～エンタープライズJava開発でのTDD適用の勘所～Hiroyuki Ohnaka
前編はこちらです 4：テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が
TDD/BDDにおける「振る舞い」の意味するところとは何なのか：いまさら聞けないTDD/BDD超入門（3）（1/3 ページ） 前回の「TDD／BDDの思想とテスティングフレームワークの関係を整理しよう」では、TDD／BDDについて、その思想と、それをサポートするテスティングフレームワークに分けて解説しました。その中で、TDD／BDDについては実際の熟練者の言葉を借り、テスティングフレームワークについては概要を触れて、その系譜をたどりました。 BDDはその名前に「Behavior」とありますが、「振る舞いとしてのテストコードを書く」とはどういうことなのでしょうか？ 難しく考え過ぎる必要はありませんが、「それは振る舞いを書いていないよ」と指摘をする熟練者が何を考えているかを理解することはBDDを習熟していく中で重要な意味を持ってきます。 本記事では「振る舞い」という言葉がどのような意味で使われ
実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜 / ATDD by genba example
ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。 PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。 トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。 ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テス
僕がTDDをやめた理由 - カタチづくり
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
AI時代にこそTDDだと思う話
GitHub Copilot、みなさん使ってますか？すでに多くの方が利用しており、「ないと困る」という方から「提案の質に問題がある」「まだまだ使えない」という方まで、様々な意見を聞きます。 筆者はGitHub Copilotに対して非常にポイティブな立場です。GitHub Copilotは使い方次第で開発速度を格段に向上させることを身をもって体験しており、これからの時代においてはGitHub CopilotなどのAIツールを使いこなせるかどうかで、個人の開発速度に非常に大きな差が出ると考えています。 重要なのは使い方次第と言う点です。前述のように様々な感想が溢れているのはAIツールの習熟度が大きく影響しているようにも感じます。AIツールは静的解析同様、利用者側の手腕が大きく問われるツールであると筆者は感じています。コマンドプロンプトエンジニアリングという言葉もあるように、AIツールを使いこ
Shin x blog Advent Calendar 2013 の 24 日目です。 先日リリースされた vagrant-serverspec を使って、テストドリブンなサーバ構築を行ってみました。 vagrant-serverspec は、サーバ、インフラの状態をテストするツール serverspec を Vagrant のプロビジョナとして実行できるプラグインです。これを使うことで、vagrant コマンドから、serverspec のテストを実行することができます。 詳しくは、@ryuzee さんの下記エントリを参照して下さい。 vagrant-serverspecを使ってプロビジョニング結果をテストする | Ryuzee.com 仕様 今回構築するサーバの仕様は下記です。PHP 5.5.x をインストールして、ビルトインサーバを起動するというものです。（※ちなみにビルトインサーバ
TDD／BDDの思想とテスティングフレームワークの関係を整理しよう：いまさら聞けないTDD/BDD超入門（2）（1/3 ページ） TDD／BDDの思想に触れ、フレームワークとしてxUnit、JBehave、xSpec、Cucumber、Turnip、TestDoxを紹介する。 前回の「テスト駆動開発／振る舞い駆動開発を始めるための基礎知識」でも紹介があったように、さまざまなテスティングフレームワークがあります。例えばTDD自体は、Kent Beck（ケント・ベック）氏が著書『テスト駆動開発入門』（ピアソンエデュケーション刊）の中で述べているように、「分析技法および設計技法であり、実際には開発全てのアクティビティを構造化するための技法」です。 TDD（テスト駆動開発）／BDD（振る舞い駆動開発）を実践することと、特定テスティングフレームワークを採用したり開発したりすることを分けて考えておかな
RSpec の入門とその一歩先へ がとてもよい記事だったので、 Python で写経させてもらいました。 https://github.com/methane/pytest-tut Ruby コミュニティと Python コミュニティの考え方の違いも見えて面白いと思います。 環境は Python 3.3 で、実行には py.test コマンドを使いましたが、 py.test の機能は特に使っていないので nose でもなんでも大丈夫です。 ファイルの作成 まずは空の実装とテストを作ります。 message_filter.py class MessageFilter: pass message_filter_test.py 最初のテストを書く py.test は .should といったメソッドを勝手に生やしたりはしません。普通に assert 文を書きましょう。 --- a/messege
最近、久しぶりに新規コードを書いたんですが、そのテスト書く中でTest::Mock::Guardってモジュール使って便利だったんで、ここらで、動作確認テストを書く上でいいな(使ってみたいな)って思ったモジュール群やテスト関連ネタを個人的なメモとしてまとめておきたいと思います。 いいなって思うPerlの動作確認テスト系CPANモジュール群 私が実際に普段使っているものから、これいいなー使ってみたいなーと思うものまで、一覧にまとめて見ました。結構いろんなモジュール使わないと、いい具合にTDDってできないものだと思います。 入門編 モジュール名 概要 参考日本語記事
テスト駆動開発から品質保証へと橋を架ける / JaSST'18 Kansai from TDD to QA
「テスト駆動開発から品質保証へと橋を架ける」 ソフトウェアテストシンポジウム 2018 関西（JaSST'18 Kansai） 基調講演 2018年6月15日（金） 東リ いたみホール（伊丹市立文化会館） http://jasst.jp/symposium/jasst18kansai.html
PHP Conrefence Japan 2011 Sep 10thでの発表資料 http://phpcon.php.gr.jp/2011/
TDDBC in TokyoをPHPUnitでやる予定なので、TDD関連資料をあさってました。 実際に手を動かして、1から2時間で最後までやり通せるTDDの資料を見つけました。 TDDに興味を持った方が最初にやるのにちょうど良い内容なので、お知らせします。 オブラブで公開されている車窓からのTDDです。Java+JUnitの構成で書かれていますが、PHP+PHPUnitで、ほとんどPHPっぽく書き直せば問題なくTDDの雰囲気を学べる内容です。 Fake It 三角測量 リファクタリングなどのタイミングを具体的に理解できるストーリー仕立てになっています。内容のボリュームもお手軽なので、TDDに興味のある方は、やってみてはいかがでしょうか？TDDの良さが体験できると思います。 PHPのコードをgithubで公開しています。「PHPでどう書くの？」って思った方は参考にしてください。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
JS開発におけるTDDと自動テストツール利用の勘所
TDD is dead. Long live testing. (DHH)
ReactでTDD（テスト駆動開発）を始めよう : 環境構築からテスト作成、機能実装までの詳解ガイド | POSTD
設計だけでコードを書けないなら断る、TDD伝道師の原点
Is TDD dead? - Google+
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
TDDはゆるく実践しても大丈夫 - 千里霧中
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング
TDDを諦めることと、RSpecをやめること - 高柴ラボ
テスト駆動開発(TDD)のゴール「動作するきれいなコード」について考えてみる - やっとむでぽん
フロントエンド（React Testing Library）で TDD（テスト駆動開発）をする
フロントエンドでTDDを実践する（理論編） - Qiita
最近行ったTDDの講演や寄稿について - t-wada の日記（旧）
【翻訳】TDD is Fun - diskogs's diary
TDDを学ぶべき10の理由 #TddAdventJp - やさしいデスマーチ
「TDDはじめて物語」 #tddbc
テスト駆動開発（TDD）はもう終わっているのか？ Part 2 | POSTD
TDD/BDDにおける「振る舞い」の意味するところとは何なのか
vagrant-serverspec で TDD ライクにサーバ構築を行う
TDD／BDDの思想とテスティングフレームワークの関係を整理しよう
Python で TDD してみる - methaneのブログ
PerlでTDD(テスト駆動開発)するなら覚えておきたいCPANモジュール群 | hirobanex.net
アジャイル開発とTDDを半年間実践してみた顛末と、これから
TDD(テスト駆動開発)をはじめたい人にオススメの資料(無料) | Act as Professional