テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
Eclipseとも連携するJavaScriptのユニットテスター·JsTestDriver MOONGIFT
まだ本格的なWebアプリケーションを作り込んだことがないので、JavaScriptのユニットテストを必要としたことはないのだが、jQueryやMooToolsなどのJavaScriptフレームワークの利用が進んでいる昨今では間もなくJavaScriptにも適切なテストを行うべきかもしれない。 キャプチャ状況 キャプチャしたデータ テストの基本となるものとしてユニットテストが有名だ。JavaScriptの場合、実行エンジンが各ブラウザに依存するのが難点だが、JsTestDriverを使えばブラウザを越えたテストができるようになる。 今回紹介するオープンソース・ソフトウェアはJsTestDriver、JavaScriptのテストフレームワークだ。 JsTestDriverはサーバとして動作するソフトウェアで、指定したディレクトリにあるJavaScrptファイルとそのユニットテストファイルを読み
本当のJavaScriptを知っているか！具体的にコードで学べる「テスト駆動 JavaScript」 | Act as Professional
本書は裏表紙に「中級技術者向け」と明記されている。JavaScriptの言語仕様に関して、入門したことない人や、関数型の言語に見地のない人は、パーフェクトJavaScriptやサイ本あたりで、JavaScriptの言語仕様を身につけてから、取り扱うことを推奨する。それぐらい価値のある内容に本書は仕上がっている。 そして、 正統派なTDD(テスト駆動開発)について理解したい JavaScript自身の言語的な特徴を押さえておきたい テストできるJavaScriptのコードを多く閲覧したい 実際のプロダクトに活用できるアプローチを数多く知りたい と、考えているJavaScriptを日頃から書いている人、携わっている人に、必ず読んでもらいたい1冊である。 全体を通じて、テストできるコードの特徴は何か、単体テストとテスト駆動環境の利点を享受できる優れた単体テストはどのようなものかをサンプルとともに
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
モックによるインターフェイスの発見 - Digital Romanticism
設計ツールとしてのモックの使い方について考える。 導入 先日、"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
なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
8. ＿＿＿_ ／⌒ ⌒＼ ／（ ●） （●）＼ ／::::::⌒（__人__）⌒::::: ＼ 簡単だお！ | |r┬-| | ＼ `ー'´ ／ 3か月前の@remore 9. ＿＿＿_ ／⌒ ⌒＼ ／（ ●） （●）＼ ／::::::⌒（__人__）⌒::::: ＼ 簡単だお！ | |r┬-| | ＼ `ー'´ ／ 後に現実を知ることになります
テスト駆動開発チートシート - やさしいデスマーチ
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
js テスト放浪記
Wandering about JavaScript Testing - Mar 8, 2011 at Test.js, presented by Shibuya.js
ウノウラボ Unoh Labs: PHPで暗号化・復号化あれこれ
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
レガシーコードは南斗聖拳(外から攻める)。新規開発は北斗神拳(内から攻める)、レガシーコード改善ガイド読書会ふりかえり - 未来のいつか/hyoshiokの日記
社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。 読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。 一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1 レガシーコード改善ガイド読書会View more presentations from Hiro Yoshioka. 今あるレガシーコードとどう向き合うか 新規にソフトウェアを作る場合はTDDでユニットテストを書いていけばいい。この方法論についての報告、参考書などは豊富にある。 レガシーコードという
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
第3回 「テスト」という言葉について ── Developer Testing、Customer Testing、QA Testing | gihyo.jp
［動画で解説］和田卓人の“テスト駆動開発”講座 第3回「テスト」という言葉について ── Developer Testing、Customer Testing、QA Testing ニコニコ動画：https://www.nicovideo.jp/watch/sm2195413 前回は、「テストが開発を駆動していくからテスト駆動開発」ということを説明させていただきました。しかしここで言っている「テスト」とは何でしょうか。 「テスト駆動開発」という名前を持っているからには、基盤となるのは当然「テスト」です。ですから、次に「テスト駆動開発のテストってどういうテスト？」という議論をしなければなりません。 結論を先に言いましょう。テスト駆動開発における「テスト」とは、品質のためのテストではありません。 「テスト」という言葉から連想するもの 「テスト」というと、みなさんはどのようなものを想像します
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
