いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ
色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。 あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。 そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル
Steve Freeman氏とのペアプロ雑感 #tddbc
README.md Steve Freeman氏とのペアプロ雑感 http://tddbc.doorkeeper.jp TDD Boot Camp 2013-07 -- TDDBC で、偶然にもロンドンから来日していたSteve Freeman氏を招くことができた。ちなみに本当に偶然の来日で、その日の夕方にご家族と隅田川の花火を見る予定だったらしい。貴重な時間である。 20分ほど講演していただき、さらに参加者と一緒にペアプロ課題に挑戦してもらった。しかもペアプロでっていう貴重な体験をさせてもらったので、そのことについてまとめたい。 Steve Freeman氏は書籍 "Growing Object-Oriented Software, Guided by Tests" （邦訳「実戦テスト駆動開発」）の共著者の一人で、Javaのモックフレームワーク "JMock"の開発者の一人。当然、自動販
TDDとパラダイムは関係ないんじゃないかなぁ - @katzchang.contexts
世の中には手続き型言語、オブジェクト指向言語、関数型言語あたりがあるとして、どれがTDDに向いてるかというと、いや特に差異はないよねという話です。 それぞれのやり方で、「手続き」なり「オブジェクト」なり「関数」なりがパターン爆発しない大きさに収まる限り、ユニットテストのコードを書くことは現実的に可能だし、RED->GREEN（もしくはその逆も）の変化を観察することに対して、大きな違いがあると思ったことはない。穿った見方をすると、書籍としてオブジェクト指向の本が多いのは、オブジェクト指向言語のパラダイムが難しいことを説明してると考えることもできる。リスコフの置換原則は我々には早すぎた道具だったのだ！！ まぁとりあえず、テスト性をよくすることで自然と高凝集かつ低結合なモジュール構成が出来上がったりします。ので、私が作る程度のプログラムでは、テスト可能な感じにまとめつつ、意図通りに変化しているこ
ボブおじさん(Bob Martin)の記事”The Pragmatics of TDD”を和訳してみた。 - 亀岡的プログラマ日記
下記のエントリを著作者に確認し、翻訳しました。 The Pragmatics of TDD とりあえず"Pragmatism"をちゃんと訳す日本語がなくて困ってしまった。最初は「TDD実践論」とか「TDD実践戦略」とか「TDD生存戦略」とかで行こうかと思ったのだけれど。いい訳あれば教えてつかーさい。。。 何度か読み返して派手な修正もしたので、大体落ち着いて読めるかと思います。Typoまだありそうなのがアレですが・・・。 ちなみに見ててわかると思いますが、渾身の訳は I've already used up my quota of curse words for the month. を この一ヶ月分のマサカリは既に投げ尽くしてしまった と訳したことです。みんなも真似していいよ！*1 *1:あかんやろと思ったら突っ込んでくださいね
Clean Coder Blog
So my last blog: The Startup Trap raised quite a ruckus. Amidst the various shouts of agreement and support, there was also a group who vehemently disagreed. I’m not going to summarize all their disagreements here, since I’ve already used up my quota of curse words for the month. But one of those disagreements struck me as something I should address. It’s the old argument of pragmatism vs. dogmati
メモ 【TDD】TDDBC Tokyo 2013-03に参加しました【勉強会】
TDD Boot Camp（Tokyo 2013-03）にphp(PHPUnit)で参加してきました。主催者・TA、会場の株式会社VOYAGE GROUP 8F 社内バー AJITOに感謝です。 勉強会 行きたい行きたいと１年くらい思ってからの勉強会でした。勉強会の温度はtwitterや発表資料などで感じでいましたが、参加してみて目の前にいる人がその人の声で聞くと、勉強に対するモチベーションはだいぶ高くなりました。 ポジションペーパー 受付をすませた後にポジションペーパーのテンプレートをもらいました。以下のような項目を埋めました。 名前 k_somemo ペアプログラミング経験 なし TDD経験 あり 言語 php テスティングフレームワーク PHPUnit エディタ・IDE Eclipse キーボード配列 日本語 ペアプロデモ @yattomさんと@grimroseさんによるFizzBu
PHPUnit の実行を自動化する 3 つの方法 | Born Too Late
皆さん, ユニットテスト書いてますか. TDD (テスト駆動開発) によるプログラミングは本当に楽しいものですが, コマンドをいちいち手動で実行するのは面倒ですよね. テストを自動化しているんだから, その実行も自動化したいですよね. この記事では, 私が仕事や趣味で使っている PHPUnit を例に, テストの実行の自動化について紹介します. PHPUnit の, としてはいますが, 他の言語で使えるテクニックもあります. なお, ここでの自動化は開発しながらの自動実行のことで, CI (継続的インテグレーション) の話は出てきません. その前に... 私の開発時のターミナルは以下のようになっています. [caption id="attachment_1298" align="alignnone" width="300" caption="開発時のターミナル"][/caption] GN
Windows環境でGrowlによるStagehand_TestRunnerのテスト結果通知 - k-holyのPHPとか諸々メモ
なんかMacユーザの皆さんがGrowl Growlって言ってるけど…どーせWindowsじゃ使えないんでしょ、って勝手にやさぐれてたら、実はWindows用のクローンがあったんです。（今更気付きました…） そろそろ、エディタの裏で動いてるStagehand_TestRunnerのAutotestをチラ見するのに疲れてきたところなので（？）、早速Growlによるテスト結果通知を試してみました。 まずは、Growl for Windowsをダウンロードして、インストール。 http://www.growlforwindows.com/gfw/ 次に、PEAR Net_Growlをインストール。 [追記] Stagehand\TestRunner\Notification\Notifierのソース見て疑問に思い、別の環境で試してみたところ、PEAR Net_Growl入れなくても大丈夫なようです
PHP で快適なテスト駆動開発を - Stagehand_TestRunner の特徴と使い方を知る | ITEMAN Blog - アイテマンブログ
先日、今年の 1 月以来となる Stagehand_TestRunner の最新バージョン 2.7.0 のリリースを行いました。コマンドラインのテストランナーを提供するこのプロダクトは、テスト駆動開発 (TDD: Test Driven Development) をより快適にすることを目的としています。 今回は Stagehand_TestRunner の特徴と使い方をご紹介いたします。 Stagehand_TestRunner とは？ Stagehand_TestRunner とは、PHPUnit や SimpleTest といった PHP のテスティングフレームワーク向けに書かれたテストの実行に特化した Piece Framework のプロダクトで、下記のような特徴があります。 指定されたディレクトリに含まれるテストの実行 指定されたファイルに含まれるテストの実行 指定されたファイル
第8回 テスト駆動開発の「サイクル」――まず受け入れテストで土台を作る | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2316518 テスト駆動開発には「リズム」と「サイクル」があります。 リズムについては前回説明しましたので、今回と次回でサイクルの話をします。 テスト駆動開発のサイクル テスト駆動開発のサイクルとは、1つの機能を実装するにあたって、どんな手順を踏んで、どういう回し方をしていくかということです。たとえば、ある1つの機能を実装したい、提供したいということになったときに、まずどういうテストを書いて、それからどういうコードを書いていくのか。 今回は、テスト駆動開発のサイクルとしてまず最初に受け入れテストを土台として作るという話をします。 そして次回、その受け入れテストを通すために、どのようにレッド、グリーン、リファクタリングというサイクルを回していくのかというお話をします。 なお、ここで説明する回し方の対象は、スタッ
HOME | deactivate-domain
You recently received an email asking you to confirm your contact details. Because you didn’t confirm within 15 days, your domain was deactivated. Final reminder: we’re holding onto your domain for an additional 7 days. After that, you won’t be able to reactivate it. To keep this domain, reactivate it as soon as possible.
TDDとテストファースト => TDDのオレオレ定義と5回リロードルール - moroの日記
自分でももやもやしてるのでツッコミ希望。 考えだした元記事 : http://techon.nikkeibp.co.jp/article/TOPCOL/20070806/137518/ TDDを紹介するときに、「TDDではプロダクトコードの前にテストを書く」という紹介のされかたが多いんですが、これはちょっと誤解を招く表現だなぁ、と思います。TDDを達成するための1つの(とても有効な)技法としてテストファーストがあるわけですが、その関係は"=="じゃなくて包含だよなぁ、と思うのです。 TDDは字義通りに解釈してもしなくても、テストが開発を駆動することが重要なわけです。駆動するというのはもちろん先にテストを書けば駆動してるんですけど、それは必要条件じゃない。 別にあとから作っても*1、 自分が作ってるモジュールを使ってみたら、APIが「ねーよwww」くらい使いづらいものであると気づいたり、とか
TDDBC on #sgt2013
Transcript ࢲϓϩάϥϚ͚ͩͲɺ 5%%ͳ͠ʹΠςϨʔ ςΟϒͳ։ൃͪ͠Ό͏ உͷਓͬͯʜ 5%%�#PPU�$BNQ�-5 �THU���� ✓�!LBU[DIBOH ✓�5%%�#PPU�$BNQ ✓�ࠂ৴γεςϜ։ൃ 5%%�#PPU�$BNQͱ ɺϖΞϓϩ͠ͳ͕Βς ετۦಈ։ൃΛମݧ͢Δ ϫʔΫγϣοϓΠϕϯτ Ͱ͢ ࠓͷΰʔϧ ʮ͋ɺͭ͗ʹ͋ͬͨΒ ߦͬͯΈΑ͏͔ͳʯͬͯ ͍͏ਓΛ૿ͯ͠ΈΔ 5%%�#PPU�$BNQͱ ɺϖΞϓϩάϥϛϯά Λ͠ͳ͕Βςετۦಈ։ ൃΛମݧ͢ΔϫʔΫ γϣοϓΠϕϯτͰ͢ ʮ͋ɺͭ͗ʹ͋ͬͨΒ ߦͬͯΈΑ͏͔ͳʯ ͍ͬͯ͏ਓʁ ��՞ਊ�՞ ۶ 4DSVNΛʜ ✓�͏ಋೖͯ͠Δਓʁ ✓�·͍ͩͯ͠ͳ͍ਓʁ ࣗಈςετΛʜ ✓�͏ಋೖͯ͠Δਓʁ ✓�·͍ͩͯ͠ͳ͍ਓʁ ͜͜ͰλΠτϧʹͲΓ·͢ ࢲϓϩάϥϚ͚ͩͲɺ
ハイプレッシャーを克服するためのテスト駆動開発の重要な「二歩目」#TddAdventJp - koeだめ 過去アーカイブ[〜2013-12-14]
TDD Advent Calender 2012, 12/11 のエントリーです。 昨日は @katzchang によるgauche unitを書いた話でした。お疲れ様です。とてもいい話でしたね。 いつもと違うプレッシャー さて、先日、サポーターズという学生と企業とを「支援」でつなげる就活サービスを行なっている人たちが主催の、エンジニア職に興味がある学生向けライブコーディングイベントに登壇し、学生のみなさんにいつもの開発を披露するという機会がありました。 いつもの開発を披露するということで、いつも通りのテスト駆動開発を披露したのですが、いつもと随分違う環境とプレッシャー下においても、テスト駆動開発はとても良い感じに機能し、これが相当に具合がよろしかったです。 ライブで思考を垂れ流してる様子をオーディエンスたち、しかもプログラマー業を生業としている人ってどんな風に仕事してるんだろうかって期待
![ハイプレッシャーを克服するためのテスト駆動開発の重要な「二歩目」#TddAdventJp - koeだめ 過去アーカイブ[〜2013-12-14]](https://cdn-ak-scissors.b.st-hatena.com/image/square/2eecb76b7b8b5c33b745f7a90fbed887f515dc93/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117126976353052%2F17680117126976357281%2F1550818890)
「愛せないコードを書くには人生はあまりにも短い」というタイトルで TDD について講演させていただきました #TddAdventJp #devlove2012 - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar jp: 2012 の 17 日目の参加エントリです。前日のエントリは [twitter:@shuji_w6e] さんの「軽量なテスト駆動開発を目指して」でした。 久しぶりのエントリです。久しぶりどころか、なんと日記の更新が一年ぶりになってしまいました……(もはや年記ですね)。 昨日、二日間開催された DevLOVE 2012 の二日目最後の(?)講演として、「愛せないコードを書くには人生はあまりにも短い」というタイトルで TDD について講演をさせて頂きました。 DevLOVE では何度か登壇の機会を頂いているのですが、昨日はいつもとは少しだけ違いました。その違いとは「イベントで私以外にも TDD の事を講演する人が複数いる」ということでした。諸橋さん([twitter:@moro])の「テストに開発をもっと駆動させたい」と和智さん
レガシーコード改善ガイド : 小野和俊のブログ
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
4つのルールと5つのコツでチラ見するテスト駆動開発入門 ～本を読んでTDDを実践したまとめ | 48JIGEN *Reloaded*
4つのルールと5つのコツでチラ見するテスト駆動開発入門 ～本を読んでTDDを実践したまとめ 2011/06/04 巷で噂のケント・ベックの「テスト駆動開発入門」読みました。めっっっちゃ良かったので、今日はその内容と実践してみた事なんかをずらずらずらずら書いていきます。独断と偏見に基づいてまとめていくよ。 めっっっちゃ良い本なのでTDDに興味のある人は全員買うが吉です。写経して手を動かしながら学べるこの内容で3150円は破格。 ※言い回しが複雑な事があって、人によってはケントベックの文章がちょっと読みづらく感じるかもしれませんが、内容は確かです。 テストコードの書き方のルール４つ 「テスト駆動開発入門」を読んで一番響いた＆実際に役に立ったテストコードの書き方たちを、4つのルールにまとめてみました。 1. 無駄なテストコードは書かない 何をテストすべきかについて、ケントベックは以下の4つをテス
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: Bobおじさんが述べるTDDの適用可能性
http://piece-framework.com/projects/stagehand-testrunner/wiki/CLI_%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E7%B6%99%E7%B6%9A%E7%9A%84%E3%83%86%E3%82%B9%E3%83%88%E3%83%A9%E3%83%B3%E3%83%8A%E3%83%BC_v3