TDDが死んだらしい - セカイノカタチ
実際には、より上位のテストを優先的に書こうという話。 http://d.hatena.ne.jp/yach/20140424 僕は以前から、ユニットテスト偏重なTDDの考え方に疑問を持ち、自分でテストを書くときは、なるべく上位のテストを書くようにしていました。 この考え方は、テストファーストな人達の評判が悪く、開発の方針を決める際に「なるべく大きな単位でテストを書くべきだ」という主張が通ることはほとんどありませんでした。 彼らの主張はこうです。 「ユニットテストを書け」「ターゲット以外はモック化しろ」。 そして、ときにはこの考え方が拡張されて、「ユニットテストを書きやすいようにクラスを設計しろ」となり(これは良いと思います)、「ユニットテストしにくいからコントローラーになるべくコードを書くな」とか言い出します。これは流石に本末転倒です。 こうして書かれたユニットテストというのは、開発者の思
【翻訳】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
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
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
TDD for Dockerfile by RSpec (severspec) (Example)
I wrote some Dockerfiles. Now Dockerfile I made is very simple but I may be restless when Dockerfile become longer and more complex. To remove such anxiety, we should write TEST for it. If we can build Dockerfile with TDD process, it is great ! There is great post about TDD for Dockerfile, "Experimenting with test driven development for docker" by PIETER JOOST VAN DE SANDE. He tried to test Docker
レガシーなプロダクトにテストで向き合う話 | GREE Engineering
はじめまして。荻原といいます。グリーのプラットフォーム部門で、サーバーサイドのエンジニアをしています。 昨年末ぐらいまで業務の空き時間にテスト周りでごにょごにょと動いていたので、今日はそのことについて書かせて頂きます。 こんな人は読むと役に立つかもしれません。 レガシーなプロダクトになんとかして突破口を開きたい PHPUnit の書き方で参考になりそうなものを探している Ruby でスマートフォンのブラウザ操作を自動化したい 経緯 こちらでも言及されている通り、サービスを運営している以上、時には技術的負債に向き合わなければなりません。GREEも歴史が長いプロダクトなので、日々コードをリリースしていく中でそういった問題に頭を抱える場面もありました。 技術的負債による副作用はたくさんありますが、どういう点に不安を感じていたのか、実際に開発の現場に立って感じたことをいくつか書いてみたいと思います
テスト駆動型開発についての議論 - ワザノバ | wazanova
http://blog.testdouble.com/posts/2014-01-25-the-failures-of-intro-to-tdd.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約7時間前 Test Double社がブログで、TDD (テスト駆動型開発) を教える場合のアプローチを提案しています。 TDDについて、同じ用語やツールを使っていても、「モックオブジェクトがありすぎて、ひどい。」「モックオブジェクトがあふれていて素晴らしい!」という異なる見解に至るケースがでてしまっているのは、理想的なゴールに至る道筋を統一したかたちで教えきれてないからだと指摘しています。 TDDの一番の効果はコードのデザインの改善であり、コードのクオリティの担保は、うまくいけば二次的な効果、まかり間違えば幻想
テストを書く - シンデレラは削らない
http://t-wada.hatenablog.jp/entry/debugging-tests 和田さーん！ テスト駆動開発（TDD : Test Driven Development）は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか？ やはりテストを書いて立ち向かってゆくのです。 チーム内にテストを書く習慣を持ち込んで三年、最初のうちは工数が増えるだけだ（あるある）、テストを書いても不具合がでるじゃないか（あるある）、システムテストでカバーすればいい（あるある）などという抵抗があり、それでも僕は淡々と雨の日も、晴れの日も、雪の日も、朝も夜も深夜も、終電後のオフィスでも、GW中の人気のないオフィスでも、自動テスト
serverspecとdocker-apiでDockerfileをTDD
serverspecとdocker-apiでDockerfileをTDD いくつかDockerfileを書いてきた．今書いているDockerfileは短くてシンプルなものばかりだが，もっと長く複雑化した時に不安になりそうだ．不安を解消するにはテストしかない．さらにテスト駆動的にDockerイメージを開発できたら素敵だ．つまり， テストを書く Dockerイメージを作成して，テストの実行 -> RED Dockerfileの編集 Dockerイメージを作成して，テストの実行 -> GREEN テストを… の流れができるとよい． ということで，RSpecを使ってTDDでDockerfileを開発するというのをやってみた，tcnksm/docker-rspec．今回実現したのは以下． Docker Remote APIでDockerfile特有のコマンド(e.g, CMDやEXPOSE)のRSp
最近行ったTDDの講演や寄稿について - t-wada の日記（旧）
こんにちは、だんだんブログ勘を取り戻していきたい和田です。このエントリは TDD Advent Calendar 2013 の 11 日目のエントリです。このエントリでは、最近行ったテスト駆動開発関連の講演や寄稿に関して、この機会にまとめておきたいと思います。 DevLOVE 現場甲子園 まず 11/9 にDevLOVE現場甲子園2013にて「テストを書く文化を育てる戦略と戦術」というタイトルで短い講演をさせて頂きました。DevLOVE 甲子園は楽天第2タワー大広間の四隅で最大四つの講演が同時に行われるという意欲的なイベントで、話す方も気合い(と声量)が必要な場でした。 この講演では、開発者が自動テストを書く文化が無かった組織に自動テストの文化を育てる際の姿勢、心がけについて短い時間でまとめました。そのときの講演資料がこちらです(ライセンスは CC BY です)。 テストを書く文化を育てる
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
TDDの効果の研究をまとめた研究 - やっとむでぽん
TDDに関連する論文をいろいろ探し回っていたのですが、今年(2013年)に書かれた、既存のTDD研究をまとめて全体像を描こうとしている研究を見つけ、しかも無料で公開されているので、紹介したいと思います。 以下のように書いてあるので、学会(?)発表用のものであって、雑誌に載ったわけではないのかな(アカデミックな話はよくわからない。査読があるかどうかが重要なんだっけ)。 This is the author's version of the work. The definite version was published in Proceedings of the 6th International Conference Software Quality Days (SWQD 2014), Vienna, Austria, January 14-16, 2014 "Effects of Tes
Knockout + ContainerJS でテスタブルにToDoリストを作るチュートリアル - うなの日記
Knockout + ContainerJS + Require.js で テスタブル にToDoリストを作るチュートリアルです。 ポイント MVVMアーキテクチャでテスタブルに MVVMアーキテクチャを採用し、View(HTML/CSS)とViewModel,Modelを分離。 ViewModel、Modelは HTMLに非依存となるため、単体テストが可能になります。 オブジェクトの生成と依存関係を、DIコンテナで一元管理 DIコンテナを利用して、ViewModel、Modelの生成と関連付けを自動化。 コンポーネント間の結合を疎にでき、テスト時のモックへの差し替えも簡単にできるようになります。 JavaScriptソースはクラスごとに分割管理 1ファイル200行超えたらメンテナンスとか無理ですよね! ということで、ソースファイルはクラスごとに分割管理します。 ソース間の依存関係解決と読
perl な web application のためのテスト情報 を #yapcasia で話してきました - soh335 memo
yapc::asia 2013 で perl の test 回りの話をしてきました。 去年からテストについて色々取り組んでいた所で、実際どういうモジュールでどうコードを書いてるかっていう説明が出来たと思います。 他の人がどういうテストを書いているかとかも気になるので、なにか気になったりしたら話したりしたいです。 継ぎ足しでスライドを作っていたら、 test::mock::guard のコードの説明がなくなっていて、なくなっていたと思ったら後ろから出てきたり、久しぶりに人前で喋ったせいか、珈琲のストローとマイクを間違えて喋ったりしました。 335さんこういうキャラの人だったのか。— ダメ人間 (@dameninngenn) September 20, 2013 335「びっくりだ！」聴衆（こっちがだ） #yapcasia— ひさいち (@hisaichi5518) September 20,
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 プロダクションコードのように
実践TDD! テスト駆動開発入門
となっています。実際にどんなことをやるかは後ほど触れていきます。 それでは、始めていきましょう！ * QUnit導入 まずはQUnitを使うべく、以下のHTMLとJSを用意しました。 index.html <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>QUnit Example</title> <link rel="stylesheet" href="http://code.jquery.com/qunit/qunit-1.10.0.css"> </head> <body> <div id="qunit"></div> <script src="http://code.jquery.com/qunit/qunit-1.10.0.js"></script> <script src="tests.js"></script
テスト駆動開発を継続する
2013年はじめのTDD Boot Camp in 大阪 外伝 の資料です。 http://kokucheese.com/event/index/64957/
オブジェクト指向プログラミングにおける単体テストのしかた - masateruk’s blog
この記事は TDD Advent Calendar 2012 の最終日の記事です。前日の記事は@biacさんの「[コラム] テストファーストとは何か?: TDD.NET」、初日の記事は@sue445さんの「Try Dream Development : 夢の開発を始めよう #TddAdventJp - くりにっき」です。 TDD Advent Calendarの記事なのですが、TDDというより単体テストの話です。単体テストのやり方について人それぞれやり方があるかと思いますが、自分が単体テストをするときの手順をまとめてみました。以下がその手順です。 テストするメソッドを決める。 メソッドの仕様を確認する。 事前条件をいくつかに場合分けする。 上で分けた場合ごとに、テストケース用のメソッドをつくる。 テスト対象のクラスのインスタンスを生成し、場合分けしたひとつの事前条件を満たすコードを追加する
TDDはじめましたが。 #TddAdventJp - k_0kamotoの日記
このエントリは、 TDD Advent Calendar jp: 2012 の 日目の参加エントリです。前日のエントリは @YasuOzaさんのTDDを取り入れたい誰かのためにでした。 私のいる職場では1000行を超えるメソッドやisなんたらっていうメソッド名で戻り値がStringで"falus"だったりするのが散見されるんですが、今回はそんなウンコードがあるよ、酷いよね！っていう話ではなく、そういう職場にTDDを導入しようとしたらどうだったかっていう話を書こうと思います。 私は数年前、デスマにやられました。 リリース前からリリース後まで爆発炎上し、チームメンバーは疲弊し、お客様にもご迷惑をたくさんかけてしまいました。 この反省から、チームの改善を模索するようになりました。 もっと良いシステムを作り、お客様に喜んでいただきたい。 チームにもっと楽しんで仕事をしてもらいたい。 そう思うように
ひのきの棒を駆使してレガシーコードに立ち向かう #TddAdventJp - PoohSunny's blog
このエントリは、TDD Advent Calendar jp: 2012 : ATNDの20日目のエントリです。 昨日は、@mike_neckさんのIPA 平成24年度 システムアーキテクト試験 午後2 問1 解答例 with TDDでした。 今日はTDD初心者がひのきの棒（覚えたてのなけなしの知識）を使ってレガシーコードに立ち向かう話をしようと思います。 レガシーコードにTDD？ TDDと聞くと、なんとなく新規コードや、テストが既にある程度整っているプロダクトに対して行うものというイメージを持つ方もいらっしゃると思います。 というか私がそうでした。 しかし、もちろんですがTDDはレガシーコードにも有効です。 TDDBCなどに参加していいなーと思って、最低限の知識はキャッチアップしてみた。 これからもっと武器強くしてレベルアップしたいと思ってるんだけど、 仕事ではレガシーコードばっかで、T
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DevOpsDays TLV and TDD = Test Driven Dev - DZone DevOps