テスト自動化パターン言語プロジェクト これは、関西検証コレクション にて議論された、テスト自動化の暗黙知について、パターン言語へとまとめる試みを行っているプロジェクトです。 表現のおかしな所や異論がある場合は、Issuesに投げてもらうか、Forkしてプルリクをいただければ全力で検討を行います! ライセンスについて この 作品 は クリエイティブ・コモンズ 表示 3.0 非移植 ライセンスの下に提供されています。
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか? 私が何かを見逃したのでしょうか? 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
最近の RSpec は、それまで obj.stub(hoge: value) と書けたものが、 allow(obj).to receive(:hoge).and_return value と書かないといけなくなったりとか、正気の沙汰とは思えないような変更をしたりするので、何年かぶりに Test::Unit を使ってみようとリハビリ中です。 RSpec は、テストケースを入れ子にできたり、テストケースや example がクラスやメソッドではなく、文字列で自由に書くことができたりしたのが良かったのですが、最近の Test::Unit ではそれもできるようになっています。 [ruby-list:48926] [ANN] test-unit 2.5.2 このリリースはとみたさんに使ってもらえるように改良したリリー スです。新しく追加した--locationはRSpecの--line_number
後編を公開しました(2014/10/8) これは、テスト駆動開発(TDD)とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2~3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
JavaScript Advent Calendar 2011 (フレームワークコース)6日目です。この前のエントリーで予告したとおりmochaを使ったフロントエンドでのテストについて書きます。ちなみにこの前エントリー書いたときは0.2.0だったんですけどすでに0.3.2です。 必要なファイルを読み込んでこんな感じで書きます。jQueryに依存してるみたいなのでjQueryも読み込みます。 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="utf-8"> <title>mocha sample</title> <link rel="stylesheet" href="mocha.css"> <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.0/jquery.m
JavaScript Advent Calendar 2011 (Node.js/WebSocketsコース)3日目のhokacchaです。Node.jsのテストフレームワーク、mochaについて書きます。 mochaはTJが新しく作り始めているテストフレームワークです。ドキュメントを見ればできることは大体書いてありますので、ドキュメントを元にどういうことができるのかを解説していきます。現時点でのバージョンは0.2.0です。 http://visionmedia.github.com/mocha/ shouldについて まずmochaでどういうことができるかの前にshouldについて解説しておきます。mochaのドキュメントには特に説明もなくshouldが使われていて、shouldでどういうことができるかわかってないと、ドキュメントを読んだときにmochaの機能なのかshouldの機能なの
プログラミング (iOS, JavaScript, Jenkins, Sikuli) とMacやiPhoneなどの話題が中心のブログ JavaScriptでテストとコードカバレッジ取得するためのツールやフレームワークは沢山あるので、最近ちょこちょこJavaScriptに手を出しはじめたばかりの人間にとってどれを使ったらよいのかわからなかったりします。 また、それをするためのボイラープレートコードが必要だったりして、わりと面倒そうだと思って二の足を踏んでいたのですが、GitHubにあったテンプレートを利用したら、簡単にMochaとIstanbulでテストとコードカバレッジ取得ができるようになったので、その手順を紹介します。 インストールと実行 Nodeで利用するには、件のテンプレート(nodejs-tdd-boilerplate)を導入するだけです。 これを雛形に利用するとよいでしょう。 $
対象 飲み物自動販売機 Ver 2.0 課題を解くにあたって大事な事 課題を全部解くのを目標するのではなく、ワークショップの学習成果を最大化するように心がけましょう! ペアプロはこまめに交代するようにしましょう!10分ぐらいが目安です! TDDは「きれいで動くコード」を目指します。必要に応じて各自独自にリファクタリングを心がけましょう! 課題の箇条書きはTDDのRED->GREENの1サイクルに対応している訳ではありません。やりやすいように仕様を整理・分割して、スモールステップで進めましょう ステップ0 お金の投入と払い戻し 10円玉、50円玉、100円玉、500円玉、1000円札を1つずつ投入できる。 投入は複数回できる。 投入金額の総計を取得できる。 払い戻し操作を行うと、投入金額の総計を釣り銭として出力する。 リファクタリング (今後の仕様変更に備えて実装とテストをリファクタリングし
rspec-2.11 がリリースされましたね。いくつかの変更点の中に、今後は should ではなく expect を推奨し、デフォルトでは expect のみが有効化されるようになる、というものがありました。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax 個人的にこの変更は説得力に欠けるなーと思っていて、 expect 推しにする理由が should は Kernel にはえるので Kernel を include しない BasicObject のインスタンスに対して should を呼ぶとおかしくなる 標準ライブラリ delegate は Kernel のメソッドの一部だけを include するので rspec と delegate のどちらが先にロードされるかによって should の挙動
Railsエンジニアになってから1年半くらいが経ち、社内のRailsのプロジェクトを全部で5つくらい触って、今やってるAbilie*1でようやく人並みにテストを書いてる気がしてきたので、現時点でやってるテストの方法をまとめておく。 テストのルール的なの rspecでは必ずモデルのテストは書くようにしてる。ヘルパーも大体書いてるけど、コントローラやルーティングのテストはあまり書いてない。 というのも、コントローラーのコードを極力短くしてモデルを太らせているのでコントローラのテストはあんまり意味が無い気がしていて、その代わりにCapybaraでテストを書いておけば十分なんじゃないかなと思ってきたから。Capybaraは書いてるので、そういう意味では書いてるとも言える。 社内の管理者だけが使える管理画面も作ってるけど、そっちはテストあんまり書いてない。ここは動かなくなっても一般ユーザーには影響が
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でサ
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
初めまして、リコーの沖田です。この度私もこの blog を書くことになりました。以後よろしくお願いいたします。 みなさんテストは好きですか?私も含めて私の同僚は皆テストが大好きなので、しばしばテストの議論で白熱しすぎてしまいます。今日はそのテストの中から Mock(モック) と Stub(スタブ) について書いてみたいと思います。 Test Double まずテストにおける Mock と Stub についてですが、これらは Test Double という概念の一部です。Double とは代役という意味で、テスト対象となるシステムが依存する外部のコンポーネントの代わりに、それらしく振舞ってくれるコンポーネントを代役として利用しようということです。 例えば Web アプリの Controller の単体テストがしたい場合に、Model の実装が完了するまでテストができないっていうのでは大変です
2009年07月05日13:34 Ruby CucumberとWebratの組み合わせが素晴らしすぎる UK STUDIO - Cucumberの登場でRailsのテスティング環境が変わった Cucumberがアツい - moroの日記 Webratがスゴい(続:Cucumberがアツい) - moroの日記 Cucumber にふれてみた - yuum3のお仕事日記 この辺りの記事を読んで、「Cucumber」って何か凄そうだなぁ、使ってみるか!と思ったささたつです。こんにちわ。今日も暑いですね。。。(*´Д`) Cucumber にふれてみた - yuum3のお仕事日記 Cucumber自体は日本語などの自然言語でテストシナリオを書けるフレームワーク的なもので、実際のテスト機能は含まれていません。ここでは実際のテストはWebratというWebアプリの受入テスト用ソフトでおこないます。
ADT 0.9.7から追加された「Library Project」により、複数のアプリケーションから参照できるライブラリィプロジェクトを構成できるようになったのは前回書いた。 ADTによるLibrary Projects Library Perojectにより、アプリケーションはライブラリィコードを共有できるようになったので、とても便利になったのだが、副作用として困った問題が発生する。それはAndroid SDK独特のInstrumentationを利用したテスト時である。 Library Project以前は、ライブラリィプロジェクトであってもAndroidプロジェクトとして管理する限りは、Android Package(.apk)を生成することが出来た。Instrumentationによるテストはテスト用のパッケージと分離されていることを前提にしている、他のパッケージをテストすることが
ブログ初ポストはCakePHPを使ったテスト駆動開発です。 CakePHPはユニットテストとしてSimpleTestに対応しています。 SimpleTestをインストールするだけで、モデルやコントローラ、シェル、ルーティングクラスなどのユニットテストが出来るようになります。 今日はこのCakePHPとSimpleTestを使ってテスト駆動開発の流れを説明します。 ただ、僕自身テスト駆動開発を学んだのは去年のCake祭りなので、至らない点が多々あります。 もし何かあれば、コメントでご指摘ください。 今更感もありますが、この場を借りてCake祭りでテスト駆動の指導をしてくださった、@sizuhikoさんに感謝します。 開発手順 まずは開発手順を示します。少し細かいですが、テスト駆動では以下のような順で開発していきます。 設計する。 テストケースを書く。 テストケースをデバッグする。 コー
前回挙げたチュートリアルはやってみましたか? 快適なテストライフを送ってますか? テストケースをたくさん書いていると気づくのは、フィクスチャがメンテナンスの邪魔をするということ。 フィクスチャに初期データを定義すると、それを気にしながらテストケースを作ることになります。 これがとても面倒くさいんです。 これを解消すべく、今日はモックを使ったテストケースの書き方を紹介します。 モックとは SimpleTestのモックで参考になるのは、以下の書籍です。 Webアプリケーションテスト手法 著者: 水野 貴明 (著), 石井 勇一 (著), 新藤 愛大 (著), 岸田 健一郎 (著), 荻野 淳也 (著), 安井 力 (著), 田中 慎司 (著) 出版社: 毎日コミュニケーションズ 発売日: 2008/7/25 この書籍のp154にモックについて以下のように書いてあります。 モックを使うと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く