JavaScriptのテストについて本気出して考えてみた(2) - 愛と勇気と缶ビール
前回からの続きで。 DOMエミュレーションの戦略 一方で、本物のブラウザを使わずに何らかのJavaScript実行環境でDOMをエミュレートして、その上でテストを走らせよう、という戦略もある。 この分野の大御所はEnv.js(http://www.envjs.com/)ということになっているのだけど、Env.jsのイヤンなところは導入がめんどくさい所である。何がめんどくさいって、antでビルドしなくちゃいけない。テストのためにどの程度の環境構築コストをかけられるかは状況において違うだろうが、例えばJSをメインでやっているエンジニアが「ちょっとテスト環境整えたい」っていう時にantから入れて頑張るだろうか？Javaの経験や、こういうビルドツールの導入/利用の流れに慣れている人だと全然問題ないレベルなんだけど。 というわけで、Env.jsは結構力を入れて開発されたものではあるのだろうけど、僕に
にひりずむ::しんぷる - make test で Test::mysqld を永続化させる方法
実際にどうやってんのかなーって話をあんまりしてなかったので。 まず、こんな感じのモジュールを t/lib/Test/MyApp/mysqld.pm とかで作って M::I::TestTarget の default_test_target() で `make test` を書き換えてやり、t/script/setup_mysqld.pl に とか書いてあげます。 それぞれのテストでは、Test::MyApp::mysqld->setup で mysqld を立ち上げるようにして置けば、 prove で個別にやった時は、それぞれ立ち上がる make test したときは、最初に立ち上げて、あとは使いまわす という感じになります。 ポイントとしては、 $ENV{TEST_MYSQLD} に Test::mysqld のデータ構造をそのまま JSON にして突っ込む Test::MyApp::m
Every XS authors should use Test::Valgrind - tokuhirom's blog
Test::Valgrind is a perl wrapper for valgrind(1). T::V helps to find invalid memory operation. You can use it by command line like following: prove --exec 'perl -Iblib/lib -Iblib/arch -MTest::Valgrind' t/*.tOr use it as test script. You can put it on xt/. use Test::More; use Test::Requires 'Test::Valgrind'; leaky();Latest stable version of valgrind is not supported OSX 10.6, yet. But, you can inst
Test::QUnit - mozrepl経由でコマンドラインからJavaScriptのテストを実行する - 愛と勇気と缶ビール
マクラ - JavaScriptのテストについて テストのないコードはコードではなく、テストを書かないプログラマはプログラマではなく、テスティングフレームワークのない言語は言語と呼ぶに値しない。と以上のような偉そうなことを言う資格は全くないし狂信的でもない僕ですが、少なくともまともに動くコードであることを証明するために、人並みにはテストを書きます。 それでまあ、最近JavaScriptばかり書いてるのですが、JavaScriptのテスティングフレームワークって大体以下のようなものに分かれると思っています。 ブラウザ上で動かすことを前提としたもの(JsUnit, QUnitなど) RhinoやSpiderMonkeyなど、ブラウザから独立したJavaScriptエンジンで実行することを前提としたもの(JsUnit, QUnit-TAPなど) 2. に加え、env.js(http://www.
Perl Monger は Test::More の subtest が便利すぎるので頭にいれておくべきだと主張したい俺がいる件 - tokuhirom's blog
Test::More の 0.94以後(2009-09-02)では subtest という機能が導入されており、これが非常に便利なのだが意外と利用されていないようなので、ちょっと宣伝させてもらいますね。 以下は Data::Recursive::Encode のテストケースなのだが、似たようなケースが頻出するわりに、抽象化するのが面倒だし、わけわからなくなること必至であり、かつまた、こんなものを複数のファイルにわけていてはメンテナンスが面倒なことは考えるまでもない。 チミチミと似たような数行のテストをかいたファイルを複数つくるぐらいならば、このように subtest の利用を考えるべきだとおもう。 ただし、これも他のツール同様、なんにでも適用すればいいというものではなく、使い方をまちがえれば、関係ないものがゴッチャリはいった .t ができあがるので注意するべきだろう。 use strict
Day 13: use Plack::Test to test your application
Testing There are many ways to test web applications, either with a live server or using a mock request technique. Some web application frameworks allow you to write an unit test using one of those methods, but the way you write tests differ per framework of your choice. Plack::Test gives you an unified interface to test any web applications and frameworks that is compatible to PSGI using both moc
Test::Moreでテスト事始め - JPerl Advent Calendar 2009
はじめまして。 最近Perlを始めたmyfinderです。 ほかの方が書いたCPANモジュールを紹介したりそれらを使ったTipsを書くCasual Trackということで、今回はテストに関連するモジュールについて書きます。 プログラムの「テスト」 テストを書くというのはデンタルフロスを使うようなもので、誰もが良いことだといいつつ、実際には軽視されがちだ。 なんて言われることもありますが、実際テストがないとプログラムの改修とか引き継ぎとかが非常に大変になりがちです。 また、CPANにアップされているモジュールの中には、モジュール本体よりもテストコードの量の方が多いものも多々あります。 なのでプログラムの質を保証したり、内容を的確に伝達するにはテストが欠かせないものであることは間違いないと思います。 早速使ってみる 例えば消費税の計算をしてくれるConsumptionTax::JPというモジュ
ドキュメントとテストコードつきのPerlスクリプトを書く方法 - kazuhoのメモ置き場
Re http://d.hatena.ne.jp/perlcodesample/20091130/1258979624, http://mt.endeworks.jp/d-6/2009/12/scriptsubimport.html スクリプトとコードとテストを単一のファイルにまとめたい*1という需要が、かねて自分の中であったので教えを請うた結果、以下のような感じで書けばいいことがわかった。 #! /usr/bin/perl use modules...; my $global = ...; sub foo { ... } sub bar { ... } run_tests() if $ENV{HARNESS_ACTIVE}; # メインのコード foo(); bar(); ... sub run_tests { ... exit; } __END__ =head1 NAME my_scr
Test::LoadAllModules で全てのモジュールがuseできるかテストする - JPerl Advent Calendar 2009
前置き みなさんこんにちは、dann です。 こちらは hacker track ということで、僕がつくったモジュールの一つを紹介したいとおもいます。今回ご紹介するモジュールは Test::LoadAllModules です。 本題 Test::LoadAllModules は非常に小粒なツールですが、なかなかいいモジュールなんじゃないかと自分でもおもっています。 モジュールを作るときには、「このモジュールがuseできるか」というようなテストをすることはままあります。00_compile.tなどで以下のようなコードを書いたり、モジュールごとのテストでuse_okするコードなどを書いているのではないでしょうか。 例えば、従来は、毎回以下のようにコードを書いていました。モジュールが増えるとuseできるかのテストするコードが増え、書き忘れたりするため冗長です。 use strict; use T
Kazuho@Cybozu Labs: Perl のテスト用に MySQL 環境を自動で構築するモジュール Test::mysqld を書いた
ORM やウェブアプリケーション関連のライブラリなどのテストケースを書くにあたっては、 RDBMS へのアクセスが必要になります。しかし、SQLite のようなスタンドアローンのデータベースと比較すると、サーバ型データベースである MySQL に接続してテストを書くのは、既存の MySQL の権限設定やデータベース名を気にする必要があったりと、いろいろ不便です。そこで、MySQL のインスタンスをテンポラリディレクトリに自動生成し、テストが終わったら削除してくれる Perl モジュール Test::mysqld を書きました。こんな感じで使います。 use DBI; use Test::mysqld; use Test::More; my $mysqld = Test::mysqld->new( my_cnf => { 'skip-networking' => '' }, # TCP接続を
prove (Test::Harness) コマンドの --state オプション - daily dayflower
テストが膨大になっていくと，あるテストでは時間がかかったりして「そのテストはもう成功することがわかっとるっちゅうねん；失敗するテストだけ再テストしたいっちゅうねん」ってことになったりします。そんなときに使えるのが prove コマンドの --state オプションです。 --state オプションに failed という引数をわたすと，「テストの対象は前回 fail したテストスクリプトのみ対象」という意味になります。ステートを保存する save と併用して指定してみます。 % prove --state failed,save No saved state, selection will be empty Files=0, Tests=0, 0 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU) Result: NOTESTS「No save
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
にひりずむ::しんぷる - JavaScriptにTAP形式でテストするライブラリってないのかな？
にひりずむ::しんぷる - Win32::API::Structがwarnings吐きまくる