第56回PHP勉強会@関東で PHPUnit について話してきた http://blog.yuyat.jp/archives/1386
http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった (この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ)。 ユニットテスティングは
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の一番の効果はコードのデザインの改善であり、コードのクオリティの担保は、うまくいけば二次的な効果、まかり間違えば幻想
諸事情により研究で使うシミュレータを変更せざるを得なくなってしまった森です.心が折れたので,気分転換に昨夏某所で少しだけ弄ったNode.jsを勉強がてら一年ぶりに触っています.一年も経つと様々な新しいモジュールも公開されており,やはりこの界隈は発展が目覚ましいなと感じています.なかでもテスト環境はかなり整えやすくなっているのではと個人的に思いました.そこで今回はJavaScriptでの簡単なテストやその自動化の方法について紹介したいと思います. テストツールの紹介 見て分かるように,主要なものだけでも色々な選択肢があります.ここで挙げられているJasmineやMocha, BusterJSなどがいわゆるxUnitとよばれるようなテスティングフレームワークになります.もちろん全て紹介するわけにはいかないので,今回は MochaやChaiなどを使ってテストを行いたいと思います. node.js
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
PHPでテストを書くというとPHPUnitがデファクトスタンダードで、次がSimpleTestでしょうか。 以前はインストールも大変でしたが、今となってはcomposer使えば楽ですし、実績もあります。 でも、本当にこの2択でPHPらしい開発ができていますか? たとえば、テストケースのクラスを用意することが前提になります。 ちょっとPHPのコードを書いてテストしたいときもです。 たとえば、以下のようなロジックを書きたいとします。 <?php $users = [ '太郎' => 'male', '花子' => 'female', '一郎' => 'male', ]; // この$usersから男性('male')のものだけを抽出したい $males = [ '太郎' => 'male', '一郎' => 'male', ]; ?> 普通にPHPUnitでTDDでとなると、それなりに面倒です
4つのルールと5つのコツでチラ見するテスト駆動開発入門 ~本を読んでTDDを実践したまとめ 2011/06/04 巷で噂のケント・ベックの「テスト駆動開発入門」読みました。めっっっちゃ良かったので、今日はその内容と実践してみた事なんかをずらずらずらずら書いていきます。独断と偏見に基づいてまとめていくよ。 めっっっちゃ良い本なのでTDDに興味のある人は全員買うが吉です。写経して手を動かしながら学べるこの内容で3150円は破格。 ※言い回しが複雑な事があって、人によってはケントベックの文章がちょっと読みづらく感じるかもしれませんが、内容は確かです。 テストコードの書き方のルール4つ 「テスト駆動開発入門」を読んで一番響いた&実際に役に立ったテストコードの書き方たちを、4つのルールにまとめてみました。 1. 無駄なテストコードは書かない 何をテストすべきかについて、ケントベックは以下の4つをテス
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや?TDD とは何ぞや?ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは?」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する? - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
Joel on Softwareに面白そうな記事が載っていた。 とはいえ、どうも僕の英語力では完全な読解が難しい。会話を書き起こしたものなので当然ながら文体が会話調で、僕にはなかなか理解が難しいのだ。以下で僕の読み間違いがあれば指摘して欲しい。 さて、冒頭で Joel 氏はこう言っている。 Joel: There's a debate over Test Driven Development... should you have unit tests for everything, that kind of stuff... a lot of people write to me, after reading The Joel Test, to say, "You should have a 13th thing on here: Unit Testing, 100% unit tests
テスト駆動開発入門ネクストステップ 1. テスト駆動開発入門 ネクストステップ 井芹洋輝 TDD Boot Camp 東京 for C++ 2011/10/8 @国立情報学研究所 2. 謝辞 • 主催の今給黎さん • 和田さん、会場提供、スタッフの方々 • 参加者の皆さま 深くお礼申しあげます 3. 自己紹介 • 井芹 洋輝(@goyoki/id:goyoki) • 組み込みエンジニア • WACATE実行委員/TDD研究会 • 講演/執筆: – XP祭り関西「ユニットテストの保守性を作りこむ」 – Androidテスト祭り「テストの活用による開発効率化」 – 並カン「FPGA/HDLを活用したソフトウェア並列処理の構築」等 4. 概要 本講義はTDDの基本サイクルを学んだ方 が対象です。 本講義ではTDDを開発で実践するための 知識、TDDについて自立して学習を進め るための情報を学び、
設計ツールとしてのモックの使い方について考える。 導入 先日、"Mock Roles, not Objects"の日本語版「ロールをモックせよ」を公開しました。この論文は2004年に書かれたもので、著者はSteve Freeman氏、Nat Pryce氏、Tim Mackinnon氏、Joe Walnes氏という豪華メンバーです。また、Steve Freeman氏とNat Pryce氏は『Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))』(いわゆるGOOS)の著者でもあり、"Mock Roles, not Object"で語られている思想はGOOSのベースになっているとも言えます。 今回は、この"Mock Roles, not Objects"(以下、MRnO
PHPでテストケースを作成する場合、ネイティブ関数を使っているようなコードに対してテストを実行しようとすると、どうしても環境に依存したり、実リソースにアクセスする必要が出てしまうことがあります。 この記事では、そのような問題に対する対処法を提示します。 経緯みたいなもの 先日もWeb APIをコールするPHPライブラリを書いていたのですが、HTTPをたたく部分のテストを切り離せず、もやもやしていました。 ちょっと前にPerlのTest::Timeというライブラリを教わって感動していたのですが、PHPでもネイティブ関数をオーバーライドできたらどんなにすばらしいだろう、などとぼやいていたのです。 そんなときに、@takimoにPHP 5.3ならオーバーライドできるよねって言われて、ハッと思い立ってテストに組み込む方法を考えてみたところ、割とスマートに実現できそうな方法が見つかったので、方法論の
11/07/07 PHPだけでコードやテストを保存したら自動でテストを実行しGrowlへ通知する環境 はじめに言っておきますが、これはリスペクトです。 コードやテストを保存したら自動でPHPUnitを実行しGrowlへ通知する環境 | Act as Professional - プロとしての行為 パクリではありません。 パクリではありません。 大事なことなので2回言いました。 上記 HIROCAST さんのブログを昨日拝見し、これはあのツールのブログを書く時が来たと思いました。 そのツールとは Stagehand_TestRunner - テスト駆動開発のためのテストランナー - Piece Framework です。 Stagehand_TestRunner は、PHP テスティングフレームワークの実行を強力にサポートするツールです。対応フレームワークは、PHPUnit
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く