本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを

第3回次期バージョン1.8に見るTestLinkの過去・現在・未来 TestLink日本語化部会 2008-10-17

LinuxにiptablesのNAT設定とtcコマンドでネットワーク遅延環境を模擬的に構築してみたので、その手順を以下に記載する。欲を言えばクライント、サーバ側はStatic Routeに従ってルーティング出来るようルータールールの設定をしたかったが、リソース(主に時間)の関係上割愛。 今回はMacのVMWare fusionで下記の3環境を用意した。左下のCentOS(ルーター部)以外は特にLinuxでなくとも良い。 192.168.11.8 +------------------+ | Kali Linux |-----+ +------------------+ | +------------------+ | +-----------+ | CentOS (iptables)|-----+-------| BackTrack | +------------------+ eth0

ども、初老丸です。 tl;dr Linux において tc コマンド（Traffic Control）使ってネットワーク遅延やパケットロスを疑似的に発生させることが出来るとのこと。今まで tc コマンドの存在すら知らなかったペーペーで恐縮だが、参考サイトをまねて遅延やパケットロスを発生させてみたい。 参考 http://linux-biyori.sakura.ne.jp/setting/st_netem.php http://labs.gree.jp/blog/2014/10/11266/ man tc 以下の環境で試す。 $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS" ひとまず ma

sudo yum -y update sudo yum install gcc make openssl-devel wget http://download.joedog.org/siege/siege-latest.tar.gz tar zxvf ./siege-latest.tar.gz rm -f siege-latest.tar.gz cd siege-3.1.2/ ./configure && make sudo make install cp doc/siegerc ~/.siegerc 実行 urls.txtからランダムにURLを抽出して、10秒間300同時接続でアクセスをする siege -c 300 -t 10S -b -i --log=/tmp/siege.log -f /usr/local/etc/urls.txt sample.jp に対して、同時ユーザー数は30

技術部の松尾(@Kazu_cocoa)です。 最近、 @moroや私を中心に、テストから開発を駆動するという方向で、とある活動を始めました。その活動の中では、 @t_wadaさん を 技術顧問 として巻き込んで活動を進めています。そんな取り組みを少しここにまとめます。 取り組みの前段階 先日、私はテストエンジニアというロールに焦点を当ててテストという言葉に対する2種類の話をいたしました。TDDのようにテストによって開発を駆動していく側面の話と、人の認知・感じ方に寄った仕様自体含めてテストしていく側面の話です。 クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアのあり方〜 を開催しました！ クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアvol.2 Testing編〜 を開催しました！ その際、会の傍でt_wadaさんらと私たちが開発するWebアプリケーショ

技術部の taiki45 です。 現在のクックパッドでは、cookpad.com 内のデータを利用するようなプロダクトでも、cookpad.com を提供しているアプリケーション(本体アプリケーション)とは別に新規のアプリケーションとして設計・実装しています。また、すでに本体アプリケーションの一部として実装されているプロダクトについても、トレードオフを考慮しながら場合によっては、本体アプリケーションから独立した別のアプリケーションとして設計・実装することが増えてきています。これらの本体アプリケーションや、新規にあるいは本体アプリケーションから独立させて設計・実装したアプリケーションのことを「サービス」と呼んでいます。また、この本体アプリケーションから独立させることを「サービス分割」と呼んでいます。 制御できないほどの巨大な複雑なまとまりを制御するために、その巨大なまとまりと単純なまとまりに

あらかじめエクセルで作っておいて実行時にそれを取り込む。 http://s2container.seasar.org/2.4/ja/S2JUnit4.html#preparedData テストクラス全体の反映、 メソッド単位での反映と両方設定が出来る。 ・エクセルファイルの命名規約 テストクラス名.xls テストクラス名_メソッド名.xls テストクラス名_メソッド名_Expected.xls(解答側) シートはテーブル名となり、1行目はヘッダーにする。 ※ シートの左側からインサートして行く為、 外部キー制約に沿った順番でシートを並べることを忘れないようにする。 ・パッケージルール src/ ∟jp.co.hoge.logic.LogLogic src/test ∟jp.co.hoge.logic.LogLogicTest src/resouces ∟jp ∟co. ∟hoge ∟log

＊＊＊＊＊コントローラーのテスト＊＊＊＊　部分のメモ MVCフレームワークの中で最もテストが困難 →モデルやコンポ―ネントを使って処理するので ユニットテスト（単体テスト）というより、 結合テストに（近い）なりやすい。 コントローラのテストの利用場面として ‐Ajaxリクエスト ‐WebAPI ‐RSS配信 などHTML以外を戻す場合に特に有効 ・評価する項目 ‐setメソッドを使ってビューに渡す値 ‐レイアウトを除いた部分のHTML ‐レイアウトを含んだ完全なHTML ‐アクションがHTML描画ではなくreturnで終了する場合の戻り値 ※テスト対象をテストコードからロードすることがないので クラスの利用宣言は必要ない。 テストクラスは ControllerTestCaseクラスを継承する ○ビューに渡された値を評価する （コントローラーが$this->setメソッドでビューに引き渡す値

CakePHP(PHPUnit)でユニットテストを書いているのですが、コントローラーで意図したページに正しく画面遷移しているかどうかをテストしたくなり、どうやったら実現できるか試してみました。 例えば下記のページに遷移することをテストしたい場合。 itemsに関連するModel, Controller, Viewが存在する状態とします(今回はbakeで作った)。 一般的かどうかはわかりませんが、返ってきたHTML文字列の中に「商品一覧画面」という文言が存在するかどうかで判定することにしました。 テストの実行は画面から確認します。 http://localhost/test.php テストコード まずはシンプルにこんな感じ。 これは$resultがnullなためFailedになります。 ItemsControllerTest.php

AuthComponent でどうやって Mock を書くんだろうと今頃になって理解できたのでメモ書き <?php class AdminsControllerTest extends ControllerTestCase { public function setUp() { parent::setUp(); $Admins = $this->generate('Admins', array('components' => 'Auth')); $Admins->constructClasses(); // 認証まわりをセッションを使わずに mock でごまかす $Admins->Auth->expects($this->any()) ->method('user') ->will($this->returnValue(array( 'id' => '10', 'mail' => 'a.y

TEST http://d.hatena.ne.jp/devbankh/201001　モックやスタブを使った効率的なユニットテスト http://d.hatena.ne.jp/devbankh/201002　モックとスタブの違い コミュニケーション http://d.hatena.ne.jp/devbankh/20051124　簡単かつ効果的に話すために "モックオブジェクト"という言葉は、テストのために本物のオブジェクトをまねる特殊なオブジェクトを表す言葉として定着した。しかしモックという言葉は元々スタブをキャッチーにしたものでなく、[スタブを使ったのとは別の] ユニットテスト方法を用いるためのものなのだ。この記事では、モックオブジェクトのファンに好まれる相互作用中心のテストと、よく行わている状態中心のテストスタイルとの違いを説明するために、モックとスタブの違いについて掘り下げる。 目次

本連載は、テストコードをこれから書こうと考えているJavaScript技術者を対象に、テストコードの意義から、テスト駆動開発、JavaScriptでのテストコードの書き方、継続的インテグレーションなどテスト全般にわたって解説します。また、原理原則だけでなくWhyから説明し、チームメンバーを巻き込みながら開発現場に活かせる考え方を総合的に解説します。第4回目の本稿は、JavaScriptでのテストダブルの方法を、Sinon.jsというJavaScriptテストダブルモジュールを使って説明します。 対象読者 JavaScriptの基本をある程度理解している方 テストコードをこれから書こうと考えている方 テストダブルとは テストコードを実行する際に、次のような課題に直面したことはないでしょうか。 Ajaxへのサーバへの問い合わせのような外部リソースも含めた処理のテストを行う必要があるが、テストデ

渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。

数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト