STF | Smartphone Test Farm⚠️ This project is no longer maintained Active development has been moved to Device Farmer
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
開発者テストの失敗を追跡しやすくすることで大人数での Web サービス開発を加速する - クックパッド開発者ブログ
会員事業部サービス開発グループ長の村田です。 私は2015年1月から会員事業部でサービス開発エンジニアをやっていますが、2014年4月までは技術部開発基盤グループで Web サービス開発を加速させる様々な取り組みを実施していました。本稿では、開発基盤グループ時代に私が取り組んだ開発者テストの失敗を追跡しやすくする取り組みについて説明します。 クックパッドの Web サービス開発と CI クックパッドのサービス開発は、大きくても5名くらいの小さなチームが一つの機能を担当します。しかし、多数のチームが1つの大きな Rails アプリケーションを同時に変更するのが特徴です *1。 Web サービス開発を加速する工夫には様々な方向性が考えられますが、ここでは、クックパッドのようなスタイルでの Web サービス開発を加速するために開発者テストを何如に円滑にするかを考えます。 図: オムキンス クック
テスターは朝会から何を知るのか - CAT GETTING OUT OF A BAG
わたしはちょっと意地悪らしい。 例えば、あるテストケースを思いついたとする（しかもかなりの高確率でうまく動かなそうなやつ）。それをね、モノが出来上がって自分の目でちゃんと動くこと（気持ち的にはちゃんと動かないこと）を見届けるまで、プログラマに話さない。*1 とあるイベントのパネルディスカッションか何かで @m_seki から「それは意地悪だなー」と言われて、はじめてそれが意地悪なんだってことに気がつきました。そういうテストを思いついたらすぐに言ってよ！てことみたい。もしプログラマがそれを考慮しないで実装してしまったら確実にバグになるわけで、黙っていることは開発にとって何のメリットもない。 なぜ話さないのか。話せなかったのか。それなりに理由はあったんだけど、まあ、それはいいや。意地悪は良くない。それからは思いついた嫌なシチュエーションや心配事は、なるべく言うようにしてる。 ということは、わた
テストコードをES6+power-assertで書けるespower-babel 3.0.0リリース
ライブラリをES6で書いて公開する所から始めよう | Web Scratchで紹介してたazu/espower-babelをアップデートして3.0.0をリリースしました。 espower-babelはBabelの変換 + power-assertの変換を一緒にやってくれるライブラリです。 簡単に言うとES6でテストコードを書いてMochaで動かすのを設定ファイル等を作らないで出来るようにするためのライブラリです。 詳しくは以下の記事を見て下さい ライブラリをES6で書いて公開する所から始めよう | Web Scratch 追記(2016-04-15): espower-babelは非推奨で、.babelrcで直接power-assertを利用するのを推奨しています。 詳しくは次の記事を見てください・ power-assert + babel as a development tool |
実践テスト駆動開発(GOOS)読んだ - Qiita
実践テスト駆動開発を読んだ（和智さんいい仕事、ありがとう！）。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト（TDD）」と「オブジェクト指向（Object-Oriented）」と「育てる（Growing）」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは！」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト（ユニットテスト）と外側のシステムテスト（受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向
クックパッド、ミクシィ、グリー、ネクストの品質管理マネージャが本音で語る。ソフトウェアテストの課題とこれからの可能性（前編）。JaSST'15 Tokyo
クックパッド、ミクシィ、グリー、ネクストの品質管理マネージャが本音で語る。ソフトウェアテストの課題とこれからの可能性（前編）。JaSST'15 Tokyo ソフトウェアテスト分野で国内最大のシンポジウム「JaSST'15 Tokyo」が2月20日、21日の2日間、東洋大学で開催されました。 そこで行われたセッションの1つ「Web.JaSST ～ウェブ開発のテスト～」」では、ミクシィ、ネクスト、クックパッド、グリーの品質管理（QA：Quality Assuarance）マネージャが登壇し、Web開発やモバイル開発分野の品質やテストにおいて、これまで乗り越えてきた課題、現状、そしてこれからの可能性について語りました。 本記事ではその内容をダイジェストで紹介します。 中野氏（モデレータ） 今日のパネリストの方々は現場でテストをリードしている方々です。その現場で取り組んでいる内容や品質管理について
GitHub - yahoo/preceptor: Test runner and aggregator
##What is Preceptor? Today, there are a lot of testing frameworks out there, many of which are optimized for testing specific areas. A couple of these frameworks are: Mocha - The most popular unit-testing tool (according to NPM downloads), testing each individual unit/component of a system in isolation. Cucumber - A high-level acceptance testing tool that tests features through scenarios, giving p
テスト全体の良い書き方について。 #swtest_jp - うさぎ組
概要 テストをつくるときにどうやって書いたらいいのか困るという話をよく聞きます。とても簡単な例ですが、これをするだけでもずいぶんと違うという意味で、自分がよく使う例を書いてみます。（実際にはリスクベースドテストとして成立させるために更に項目を追加したものを使っています。ですが、基本はこの形であり、ここにある考え方が重要だと思っています。 つまり、ツールを使えばもっと綺麗に出来るけど、まずはMarkdownでもExcelでもなんでもいいからやれる感じで整理できる方法というところです。 僕がこの考え方を気に入っているのは、プロジェクトのリスク管理手法とあまり違わないので、別にテストではなくて、例えば「こういった人が必要」とか「こういったツールがいる」とかになるという点です。 まとめすぎると「BDD-Styleに対して、リスクという親要素を加える」というくらいです。 構成のテンプレ 基本的に3段
テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか？」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
EcmaScript6 + power-assert でテストを書く - from scratch
この記事はJavaScript Advent Calendar 2014の15日目の記事です。 さてさて、EcmaScript6に対する機運が高まっている中で、ES6の新機能の紹介記事が出てきておりますが、ES6が使えるブラウザはまだ浸透しておらず、使おうとするならばTraceur Compilerや6to5といったトランスパイラを利用せざるを得ないというのが現状です。 これらのトランスパイラも実際のプロダクトで使おうとするとまだそこまで実績がないし、いきなり本番で使うという訳にいかない人達が多いかと思っています。 ただし、ES6には慣れておきたい、、、ES6の新機能(let, template-string, arrow function, generator, promise, etc...)を使ってみたい、、、 ならばせめてテストだけでもES6で書こうじゃないか、いずれES6が来た時
おまえは今まで実行したassertの回数を覚えているのか？あるいは新しいアサーションユーティリティのご提案 - teppeis blog
JavaScript Advent Calendar 2014 11日目。 いきなり要約: Promiseや非同期テストのアサーションを簡単確実に書けるようになるesplanというライブラリのPoCを作った話。 Promiseや非同期のテストは難しい 詳しくはJavaScript Promiseの本: Chapter.3 Promiseのテストをご覧いただきたいのだが、Promiseのテストを正確に書くのはそんなに簡単ではない。 例えばmochaだと、 // 間違ったテスト1: // mayBeResolveWithOne() が1以外でresolveしたときタイムアウトエラーになる it("mayBeResolveWithOne()は1でresolveする", function(done) { mayBeResolveWithOne().then(function(value) { as
MochaがPromisesのテストをサポートしました
このpromiseオブジェクトは、resolveするので、.then の第一引数で指定したonFulfilled コールバックに true という値を渡すようになってます。 今までのテストの書き方 このgetSuccessPromiseを 1.18.0より以前は以下のように書くことでテストをしていました。 it("should manually handling test...", function (done) { getSuccessPromise().then(function (value) { assert(value); done(); }).catch(done); // <= このcatchが今回の変更での焦点 }); getSuccessPromise()の返り値であるpromiseオブジェクトがresolveされると value に true が入って assert(t
JMeter使うのだるいなーと思ってたらruby-jmeterというRubyでテストプランを書けるツールがあった | mah365
JMeter使うのだるいなーと思ってたらruby-jmeterというRubyでテストプランを書けるツールがあった。知らなかった（迫真）。 典型的なRailsアプリのテストプラン そういう訳で典型的なRailsアプリのテストプランを書いてみたのがこちら。 ユーザーログインページでCSRFトークンを取得し、常にHTTPヘッダにつけるようにする ユーザーログイン情報をクッキーに保存 といった典型的な処理を盛り込んでいます。あとはREADME.mdを読んでもらえれば大体の書き方が把握できるかと思います。 ちなみに、# Debugというコメントの下2行をコメントアウトしてもらうと、JMeter上でデバッグ用の出力を表示することができます。テストプランが上手く動かないときに、リクエストヘッダやレスポンスを確認するのに便利です。 で、これをコマンドラインで ruby sample.jmx.rb && j
テストダブル - Wikipedia
テストダブル (Test Double) とは、ソフトウェアテストにおいて、テスト対象が依存しているコンポーネントを置き換える代用品のこと。ダブルは代役、影武者を意味する。 テストを実行するには、被試験システムに加えて、テスト対象が依存するコンポーネント (DOC; Depend-On Component) が必要になる。しかし、依存コンポーネントは、常に利用できるとは限らない。依存コンポーネントがテスト環境で利用できない理由には、次のようなものが挙げられる[1]。 入手できない。 テストで使いたい結果を返さない。 実行に時間がかかるなどの、望ましくない副作用がある。 こういった問題を回避するには、依存コンポーネントを、テスト用のコンポーネントと入れ替えるテクニックが利用できる。この代用のコンポーネントを、テストダブルと呼ぶ。 ジェラルド・メサローシュは、テストダブルのパターンとして、次の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - thlorenz/proxyquire: 🔮 Proxies nodejs require in order to allow overriding dependencies during testing.
IBM Developer
ハイパフォーマンスSeleniumテスト＠サイボウズ
ShouldBee - テスト作業を限りなくゼロに
Unit testing in Ruby