GitHub - sstephenson/bats: Bash Automated Testing SystemYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
jasmine-nodeでNode.jsのBDD環境 - ひげろぐ
jasmine-nodeがnpmで入るようになってたので使ってみた。 これを使うと完全にコマンドラインのみでJasmineを使うことが可能となり、テスト結果もブラウザではなくターミナルに表示される。 自分にとってはRailsやらPHPやらのサーバーサイドプログラミングで慣れ親しんだ形でございます。 しかしTitaniumをいじってたはずがいつの間にかNode.jsの世界に迷い込んでるんだけど、あんだこれ。 準備 インストール npm install jasmine-node ディレクトリの準備 mkdir myproject cd myproject mkdir lib mkdir spec libにはテスト対象の実コードを置く。 specにスペックファイルを置く。 実コードを置く場所を変えたければspecs.jsを書き換えればよい。 Jasmineとspecs.jsのコピー スペックを走
テストに関するパターン・Mock Object（モックオブジェクト） - Strategic Choice
Q：高価または複雑なリソースに依存するオブジェクトのテストはどのように行うのか。A：定数を返す仮バージョンのリソースを作成する。どうして？データベースを利用した機能のテストを書くとします。データベースは起動に長い時間を要し、接続にも長い時間がかかります。また、リモートサーバ上に配置されていれば、テストをネットワーク上の物理位置に依存させることになります。とはいえ、データベースは開発でエラーが発生しやすい箇所なので、特にテストを実行したい部分でもあります。どうすれば？データベースのように振る舞う、実際にはメモリに存在するだけのオブジェクト、「モック」を用いてテストを作成します。 @Test public void testOrderLookup(){ Database db = new MockDatabase(); db.expectQuery("select order_no from
テストについて考える #devlove
DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ........................................
第12回 モックオブジェクト技法：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
ニコニコ動画：https://www.nicovideo.jp/watch/sm2325718 家永さんのコメント そうですね。 今「モックテスト」という言葉が出てきました。モックテスト、モックオブジェクトという技法は、『WEB+DB PRESS Vol.35』の特集1「実演！ テスト駆動開発」でも少し説明しましたが、この場で詳しく説明しましょう。 モックオブジェクト技法とは 「モックオブジェクト」「モックテスト」とは、ニセモノのオブジェクト（モックオブジェクト）をテストに使う技法です。本物のコードや本物のクラスではなく、テスト用の偽者のオブジェクトを作成し、テストを書きやすく、実行しやすくします。 詳しくは後述しますが、具体的には、テスト対象である本物のクラスと、それと協調動作するオブジェクトの偽物を使います。偽者オブジェクトは、テストの中で、テストの内容に即した動きをします。 メリ
Mocks Aren't Stubs
The term 'Mock Objects' has become a popular one to describe special case objects that mimic real objects for testing. Most language environments now have frameworks that make it easy to create mock objects. What's often not realized, however, is that mock objects are but one form of special case test object, one that enables a different style of testing. In this article I'll explain how mock obje
テスト戦略、設計、手法、技法などなどのリンクをまとめてみた - うさぎ組
WACATE 2011 夏に申し込んだので、おさらいしましょう。ということでテスト手法、テスト技法を中心としたリンクをまとめてみました。 なので今回はTDDとかテストツールとかはあまり含まれていません。 いくつかかぶっているものもありますが、多面的な表現って大切だと思うので、多少のかぶりは気にせずに選択しました。 これを読めば良いソフトウェアエンジニアとして一歩階段を上れる気がしています。 他にも参考になるものがあったら、コメントやTwitterで@kyon_mmまで教えてくださるととっても嬉しいです！ 次の形式で書いています。 WEBサイト名、資料名：発表者（敬称略）：URL カテゴリー分けしたんですが、不適切であるかもしれません。間違い等あればご指摘ください。 また、ここでのリンクに問題がある場合は削除致しますので、その場合もご指摘ください。 TwitterID:kyon_mm mai
Perlで単体テスト - yokkunsの日記
Perlの単体テスト、特にMockObjectを使ったテストについての情報が少ない気がするのでまとめてみる。 前提 モジュールは、CPAN形式であると前提。雛形は、Module::Starterで作成すると良い。 テストは、Test::Perl::Criticを入れる。 インストール $ sudo cpan Module::Starter $ sudo cpan Module::Starter::PBP $ sudo cpan Test::Perl::Critic 初期セットアップ $ perl -MModule::Starter::PBP=setup モジュールの作成 $ module-starter --module=Ysm::Example $ cd Ysm-Example $ ls Build.PL Changes MANIFEST Makefile.PL README ignor
負荷試験ツール「インターネット破壊」を公開しました : DSAS開発者の部屋
負荷試験ツール インターネット破壊を公開しました。 こちらはずっと社内で負荷試験に使用していたツールです。社内で使用していたものなので、ソーシャルアプリ向けの機能などが多少追加されていますが、もちろんんそれ以外のWebアプリケーションでも使用できます。 基本的にはApache JMeterのようなWebアプリケーションむけのシナリオ負荷試験ツールです。コマンドラインオペレーションだけで実行でき、サーバー上で簡単に負荷試験を実施できるのが特徴です。POSTリクエストなどはもちろん、レスポンスのチェックやUserAgentの偽装、ランダムな値をパラメーターにセットする機能も実装しています。 注意: 当然ながら自分の管理下にないサイトに向けて負荷試験ツールを実行するのは絶対にやめてください。非常に危険です。 物騒な名前がついていますが、これは完全にわたしの小児的感性の趣味によるところです。地震で
Refactoring PHPUnit's getMock()
Do you like this article? Subscribe to the feed to be updated about new posts on Invisible to the eye. Get to know what lies under the hood of software. If you prefer, you can follow me on Twitter. fqqdk said... I would invert certain defaults: for example I would consider good practice to not enable parent constructor by default, because I consider constructor injection better, and when mocking a
Unit Test vs Functional TestそしてClean Code - masayang's diary
Agile2008でもらったゴムバンドを未だに手首につけている。確かBob Martinだったと思うが、テスト駆動開発と「Clean Code」の関係について熱く語っていた年だ。 メソッドは短く。 メソッドが実現することは一つ。 あるメソッドのテストに色々と条件を設定しているのなら、それはClean Codeではない。 だが我々はその基本を簡単に忘れてしまう。色々とテストのための道具が揃ってきたせいもあろう。基本を忘れて一つのメソッドに色々と詰め込みすぎるとテストが大変になる。Mockがあっても、だ。Fixture使うのはさらに大変だし、Seleniumとかで入力から何から条件を与えるのはもっと面倒。そしておそらく抜けが発生する。 最近、内職でPython使ったアプリを組んでいるのだが、今回は上記「基本」を徹底するようにしている。例えばこんなコードがある。 def nearby(reque
知るだけで天地の差が出る、テスト仕様書の必須項目＆表現方法
テスト仕様書で絶対に必要な項目リスト テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号（通し番号など） テストを実施した年月日 テストを実行した担当者 障害報告票番号（発生した障害の詳細を開発グループに報告する帳票の識別番号） まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。 なぜなら、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モックオブジェクトをいつ使うか?