xUTP Magazine - ぺけま
xUTP Magazine について 『xUTP Magazine』、略して『ぺけま』は、xUTP読書会の有志による xUnitester の xUnitester による、xUnitester とそうでない人のためのウェブ雑誌です。 最新号 0004号 巻頭言 xUTP Topics: 第三回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」 TDD Live 番外編(TDD序破Q) 編集後記 バックナンバー 0003号 xUnitester Hotlinks: 第一回 和田卓人さん(下) goos 読書会への誘い 来年(2012年)のTDDBC予報 0002号 xUnitester Hotlinks: 第一回 和田卓人さん(上) xUTP Topics: 第二回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」 mockitoでサ
僕がTDDをやめた理由 - カタチづくり
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
RSpec の入門とその一歩先へ、第3イテレーション - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ、第3イテレーション』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 大きく時間が開いてしまいました(すみません…)、RSpec 入門の第三イテレーションです。 (第3回 coffee.rb の開催に合わせたライブ更新で書かれましたので、まだ詳細の説明は途中のところもあります。) 第1イテレーション 第2イテレーション 前回終了時点のコードと実行結果 この「RSpec 入門とその一歩先へ」シリーズでは、メッセージフィルタを RSpec を使って開発することで、 RSpec の機能と TDD を同時に学ぶことを狙いとしています。 前回終了時点のコードと実行結果をまず記します。 message_filter.rb class MessageFilter def initialize(*w
RSpec の入門とその一歩先へ、第2イテレーション - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ、第2イテレーション』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 #coffee.rb の写経会に招かれた(というよりは押しかけた?)ので、先日の RSpec チュートリアルの続きを記します。このエントリは写経会に参加しながらのライブ更新でした。 (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 前回終了時点のコードと実行結果 前回終了時点でのコードを以下に記します。 message_filter.rb class MessageFilter def initialize(word) @word = word end def detect?(text) text.include?(@word) end end message_filter_spec.rb r
RSpec の入門とその一歩先へ - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま
JavaScriptのテストについて本気出して考えてみた(3) - 愛と勇気と缶ビール
テストにおけるxhrのハンドリングについて 今までの記事は、「ブラウザで動くJavaScriptのテストを難しくしているのはDOMとxhrである」と最初にのたまった割にはDOMのことしか書いてないじゃないか、と鋭い人はちゃんと思ったのではないかと思う。 なのでJavaScriptにおける外部リソース操作の双璧をなすところのxhrについてもちょっと書く。 xhrによる外部リソースの操作を含むアプリのテストを（本物のサーバサイドアプリを使わずに）行う場合の方法は主に二つあると思っていて、 1. テストフレームワークの側で、xhrに対してレスポンスを返すようなモックcontroller(?)を書けるようにしておく 2. xhrそのものをモックオブジェクトにしちゃう 1. はつまり、pushによる自動化を行うようなフレームワークだと何らかの形でWebサーバを起動しているはずなので、その中でxhrか
JavaScriptのテストについて本気出して考えてみた(2) - 愛と勇気と缶ビール
前回からの続きで。 DOMエミュレーションの戦略 一方で、本物のブラウザを使わずに何らかのJavaScript実行環境でDOMをエミュレートして、その上でテストを走らせよう、という戦略もある。 この分野の大御所はEnv.js(http://www.envjs.com/)ということになっているのだけど、Env.jsのイヤンなところは導入がめんどくさい所である。何がめんどくさいって、antでビルドしなくちゃいけない。テストのためにどの程度の環境構築コストをかけられるかは状況において違うだろうが、例えばJSをメインでやっているエンジニアが「ちょっとテスト環境整えたい」っていう時にantから入れて頑張るだろうか？Javaの経験や、こういうビルドツールの導入/利用の流れに慣れている人だと全然問題ないレベルなんだけど。 というわけで、Env.jsは結構力を入れて開発されたものではあるのだろうけど、僕に
JavaScriptのテストについて本気出して考えてみた(1) - 愛と勇気と缶ビール
一週間のうちまる一日くらいは、「あーあのJavaScriptコードのテストってどうするのがいいかしら？」と考えている。 嘘です。多分45分くらい。 考えている時間の長さはどうでもいいんだけど、JavaScriptのテストは場合によっては中々ややこしい問題に成り得る。DOMなどの外部リソースにタッチすることのない「純JavaScript（オレオレ用語です）」であればブラウザ上であろうとRhino上であろうとNode JS上であろうと(理論上は)テストを動かせるのだが…。 JavaScriptであろうとなかろうと、外部のリソースに依存している（外部のリソースを操作する）コードはそうでないコードよりテストが面倒になる。ファイルR/WやDBの操作などIO系は勿論そうだし、どこかのサーバに何かしらのプロトコルで話しかけるようなコードもしかり。 JSのテストがややこしくなるのは、JavaScriptの
Test-Driven JavaScript Development in Practice | Envato Tuts+
TDD is an iterative development process where each iteration starts by writing a test which forms a part of the specification we are implementing. The short iterations allow for more instant feedback on the code we are writing, and bad design decisions are easier to catch. By writing the tests prior to any production code, good unit test coverage comes with the territory, but that is merely a welc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
