[B! testing] isdyyのブックマーク

さいきんの JavaScript テスト / Test.js - Shibuya.js 発表資料 - 川o・-・）＜2nd life

本日行われた Shibuya.js の発表資料をアップしました。さいきんの JavaScript テスト / Test.js - Shibuya.js 発表資料 View more presentations from hotchpotch JS のテスティングフレームワークのおおざっぱな説明や JavaScript テストにおける問題、それについての解決方法の一つ、CUI でのテスト、Envjs、エンドツーエンドテストにおける JS / Ajax のテスト、終わりにちらっと Phantomjs の話があります。スライドの最後にあるように、やはりまだコレだ！という JS のテスティングフレームワークは存在しなく、今後 JS のテストは『僕らが書きたいテスト』をどれだけ簡単に書ける・書く手法が確立されるかによって流行廃りは決まってくるんじゃないかなぁ、と思ってます。そのうちの一つがスライ

isdyy 2011/03/10

リンク

Kazuho@Cybozu Labs: テストケースの実行にあわせて Apache を起動・終了する方法

ウェブアプリケーションやライブラリの結合テストを行う段階になると、実際に Apache を起動してテストを実行したくなります。しかし、そのためにいちいち Apache の設定ファイルを修正して httpd を再起動して、とやっていては面倒です。特に複数のプログラムを同時に開発していると、あっちをテストしたらこっちが動かなくなって… なんてなったりして嫌気がさしてきます。そこで、テストを実行する際に、環境毎に異なる以下のような問題を吸収しつつ、テスト専用に設定された Apache を自動的に起動終了してくれる Perl モジュール：Test::Httpd::Apache2 を書きました。環境によって、インストールパスが違う (/usr/local/apache/bin だったり /usr/sbin だったり) 環境によって LoadModule の要不要や、ロードするパスが違う環境によ

isdyy 2010/08/29

testing

リンク

いまからでも間に合う開発者テスト - mixi engineer blog

はじめまして。開発部じゃない加藤和良です。最近、mixi では Buildbot をつかった継続的インテグレーションをはじめています。安定版の mixi のソースコードにコミットすると Buildbot がそれを検知し、自動的にテストが走るようになりました。ここでの「テスト」は Test::Simple や prove(1) をつかった、Perl でかかれた開発者テストを指しています。mixi の開発者テストをとりまく環境は、ここ数年でかなり改善されました。今回はその歩みをふりかえりながら、テストの無いコードベースをどこからどうやって変えていったかという話をしたいと思います。開発環境はじめに、前提となる mixi の開発環境について説明します。mixi では複数人の開発者がひとつのマシンで作業を行います。それぞれの開発者は、あらかじめ割り当てられたポートで Apache を起動し、

isdyy 2010/03/01

testing
mixi

リンク

ウノウラボ Unoh Labs: ありえるえりあ勉強会@五反田～テスト編～発表資料

こんにちは！　山本＠テスト番長です。 1/29にアリエルさんとウノウが合同で実施したピザパーティ　勉強会でお話する機会を頂きました。お集まりいただきました皆様、どうもありがとうございました。その時の資料を公開したいと思います。

isdyy 2010/02/02

testing

リンク

ユーザID妥当性チェックのテストケースを考える - 岩本隆史の日記帳（アーカイブ）

前回の記事にて、妥当なユーザIDとパスワードを決めました。そこで、さっそくバリデーション処理をBDDで実装しようとしたのですが、適切なシナリオがなかなか決まりません。たとえば、ユーザID。許可する文字種は英数字および「-」「.」「_」です。妥当な文字数は2〜24文字。この仕様で妥当となるユーザIDは、計算するのも嫌なぐらいありえます。したがって、これらをすべてテストするわけにはいきません。どこまでテストすればよいのでしょうか。また、妥当でないユーザIDのテストケースも必要です。たとえば「~」が含まれるユーザIDは「妥当でない」と判断されなければなりません。そのような文字は山ほどある（ひらがな・カタカナ・漢字・記号など）ので、これらもすべてテストするわけにはいきません。テストケース作りの指針そこで、何か指針はないかと探したところ、下記のPDFが見つかりました。ソフトウェアテスト技術

isdyy 2009/12/20

testing

リンク

YappoLogs: Ajax アプリ等の為の JavaScript コードのテストツール JSTAPd を作ってるよ

Ajax アプリ等の為の JavaScript コードのテストツール JSTAPd を作ってるよ Data::ObjectDriverをDISってる人の話題が三周目に突入した今日この頃ですが皆さんは何をDISってますか?Yappoです。 JavaScript にもテストツールが色々とあると思うんですが、 Ajax アプリの XHR リクエストとかも含めてラクチンにテストできるツールが見つからなかったので JSTAPd というツールを作りました。 http://github.com/yappo/JSTAPd 名前の通りテスト結果はTAPで出力してるのでproveコマンドとかを使ってPerlの作法でテストできます。ブラウザの連携の設定をすれば prove -v foo/hoge.t とかをコマンドで打ち込めば勝手にブラウザ立ち上げてテストコード実行してブラウザ閉じて結果をコンソールに吐いてく

isdyy 2009/10/29

リンク

Php Unit With Zend Framework Zendcon09

This document discusses unit testing PHP code with PHPUnit. It begins with an introduction to the speaker and then covers why testing is important, how to get started with PHPUnit, writing basic tests for a sample class, using features like data providers and expecting exceptions, and more advanced topics like stubs, mocks and testing databases and Zend Framework applications. The overall message

isdyy 2009/10/26

リンク

Cucumberの登場でRailsのテスティング環境が変わった

ちょっと大げさなタイトルかもしれないですが、個人的にはそれぐらいの感動。「これで勝つる!」な気分。何に勝つのか知らないけれど。今までのRailsのテストはもっぱらRSpecで書いてて、確かにこれはこれで素晴らしい。採用当初はバグが減ってその時も「これで勝つる!」な気分でした。でもやっぱり受け入れテストがネックになるんですよね。Seleniumとかも使ったりしてましたけど、ブラウザががちゃがちゃ動くし、なんとなく面倒で結局手動で確認という感じになってしまいました。そこでCucumberの登場ですよ。個人的に素晴しいと思うのはテストケースが自然文(っぽい) そんなに邪魔じゃないあたりかなぁ。テストケースが自然文っぽいというのは実はかなり大事で例えばお客さん: まずトップページにアクセスするとログインフォームがあって、そこにログインすると「ようこそ!ほげほげさん」と出すようにして欲しい

isdyy 2009/04/25

リンク

GT Nitro: カーレーシング・ドラッグレーシングゲーム - Google Play のアプリ

GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠

isdyy 2009/01/21

リンク

[PHP]ZendFrameworkで作成したControllerをPHPUnitでテストする | ブログが続かないわけ

isdyy 2008/05/18

リンク

極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ

今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。これまでは、「ユニットテストは、できる

isdyy 2008/04/23

リンク

PHPのテスティングフレームワーク - p4lifeのメモ

今回取り上げるテスティングフレームワークライブラリ，アプリケーションの品質を高めるために必要不可欠なテストですが，そのテストを実行するためのツールに関する情報を集めました． phpt PHPUnit SimpleTest lime DocTest PHPSpec phpthttp://qa.php.net/write-test.php PHP 独自のテスト機構 PHP 本体，PEAR のテストで最も良く使われる．テストファイルの拡張子は .phpt TAP*1 対応：PEAR 1.5.0 から対応 pear run-tests コマンドに -t オプションを付けると run-tests.log に TAP フォーマットのログが出力される特徴: pear コマンドが使えればテストを実行できるため，大抵の環境で動かせる GET/POST/Cookie, php.ini 設定, 標準入力をパラメ

isdyy 2008/03/15

リンク

TAPって意外と知られてないのかな - tokuhirom's blog.

http://d.hatena.ne.jp/fbis/20080304/1204606404id:fbis さんが PHP 版の prove をつくったというような話なんですが、そんなことをするよりもテストプログラムの方の出力を TAP(Test Anything Protocol) にあわせた方が幸せになれるよ。という話(もうあってるようにも見える)。TAP(http://testanything.org/wiki/index.php/Main_Page)のプロトコルにあわせて、テストスクリプトから標準出力に吐くのが吉。PHP でも PHPUnit はこれに対応してるみたい。標準出力を通じてプロセス間通信をするだけの簡単なプロトコルなので、perl の prove に喰わせれば、言語は関係ない。実際、某サービスで XMLRPC API を提供しているのだが、それを各言語の XMLRPC