Test::Fake::HTTPD で Web API クライアントをテスト · takus's blog
ある社内向け Web API のクライアントのテスト書く時にどうすべきかなと小一時間調べてみて、Test::Fake::HTTPD がよさそうなので使ってみたメモ。思うがままにレスポンス返せるし、実際に本番サーバ叩いたりしなくてもいいし、オフラインでもテストできて、だいぶテストが捗りそうです。 #!/usr/bin/env perl use warnings; use strict; use Test::More; use Test::Fake::HTTPD; use JSON::XS; use Furl::HTTP; subtest api => sub { my $response = { '/1/statuses/user_timeline/takus.json?count=1' => [ { 'created_at' => 'Thu Mar 21 07:22:25 +0000 20
プロジェクト開発におけるテスト用DBの(使い|作り)方
昔書いたような気がしてたけど書いてなかったので。 モジュールをつくっていてDB回りのテストを書きたい場合は Test::mysqldやTest::postgresql を使うこと。 CPANなんかに上げるモジュールではなく、お仕事プロジェクトのコードを書いていて DB回りのテストを書きたいケースについてです。 私はMySQLを利用しているので、Test::mysqldをつかってもよいのですが、 起動コストがそれなりにかかるのと、ローカルの開発環境には既にMySQLは立ち上がっている前提があるので、 既に立ち上がっているMySQLをそのまま利用する方法をとっています。 そこでテスト用のユーティリティクラスを紹介してみます。 package t::Utils; use strict; use warnings; use utf8; use lib './t/'; use Test::Fixtu
Perl 以外の言語でかかれたTCPサーバーをTest::TCPでテストする - tokuhirom's blog
Test::TCP の中で exec 発行すれば、groonga だろうと KT だろうと memcached だろうと、サーバープロセスのテストは簡単にできるのであって、サーバーごとにモジュールにする必要はない。以下は、groonga をテストする例。 Test::TCP は、さまざまなTCPサーバーのテストにつかわれており、さまざまな BK をふくんだ実装となっていて、これを再発明しようとすると、意外とめんどくさかったりするので、素直につかうとよいです。 use strict; use warnings; use utf8; use Test::More; use Test::TCP 1.08; use File::Temp (); use File::Which; my $bin = scalar which 'groonga'; plan skip_all => 'groonga
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
