第23回 Perlアプリケーションのテストと高速なCI環境構築術（2） | gihyo.jp
前回の（1）はこちらから。 PerlアプリケーションのCI 前回の（1）までで、Perlアプリケーションのテストとその実行に関して基本的な内容を紹介しました。アプリケーション開発にあたっては多くのテストが書かれると思いますが、都度すべてのテストを実行するのは手間がかかりますし忘れてしまうこともあるでしょう。同じことを繰り返すのであればCI環境を作り、テストを自動的／継続的に実行するのが確実です。 Ukigumo::Serverによるテスト実行結果の可視化 Ukigumoはtokuhiromさんが作ったCIを支援するWebアプリケーションです。Ukigumo::Serverはテスト実行結果をPOSTすることで、一覧化してWebブラウザから見ることができるアプリケーションです。 Ukigumo::Serverの導入はcpanmで簡単に行えます。導入と起動は次のように行います。
第23回 Perlアプリケーションのテストと高速なCI環境構築術（1） | gihyo.jp
本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回はmyfinderこと久森達郎さんで、テーマは「Perlアプリケーションのテストと高速なCI環境構築術」です。テストに利用するさまざまなモジュールから、CI（Continuous Integration、継続的インテグレーション）環境の構築、そして増えたテストを高速に実行する枠組みの構築までを紹介します。 なお本稿のサンプルコードは、本誌サポートサイトから入手できます。 テストの目的 まずはテストを行う目的を整理します。 コードを壊していないことを確認する 1人で開発するものであれば、どんな状況であれ責任を負うのは自分だけですが、チームや組織が複数にまたがる場合にはテストが重要になります。プロダクトが大きくなるにつれ、自分の開発によって想定外の機能にも影響を与えることが多くなります。逆にほかの開発者が行ったコミットによって
Test::Synopsis::Expectationというモジュールをリリースしました - その手の平は尻もつかめるさ
このたび，Test::Synopsis::Expectationというモジュールをリリースしました． https://metacpan.org/pod/Test::Synopsis::Expectation https://github.com/moznion/Test-Synopsis-Expectation 使い方や仕組み等をid:mackee_wさんの記事で紹介していただいたので，そちらの方も併せてご覧いただくと良いと思います． SYNOPSISのコメントを使ってテストするTest::Synopsis::Expectation - ぱいぱいにっき CPANに上がっているモジュールを使う時，多くの方が何は無くとも真っ先にSYNOPSISを見て使い方をザックリ把握するかと思います．とりあえずSYNOPSISのコードをコピペしてみて，動くかどうか見てみる的な． で，SYNOPSISのコード
Test::Power 0.09 supports ArrayRef and HashRef - tokuhirom's blog
Hi, I released Test::Power 0.09 today. Test::Power is a library for testing. It taps the calucuration progress in the test code, and dump it if the test case was failed. In this version, Test::Power shows the progress in the ->[] operator and ->{} operator. Here is an example. This is a test code using Test::Power. use strict; use warnings; use utf8; use Test::More; use Test::Power; my $a = +{ a =
意識が高まりゆき、Test::More::Hooksというモジュールかいた #perlましましブログ | ましましブログ
先日から社内で、今年度の新卒向けにテストの講師やってくださいと仰せつかり、 別に誰かに強制されたわけではないのですが、去年までの講義資料だとチュートリアル的な感じで終始してしまったいたので、 資料をスクラッチで書き始めてしまい、しばらく苦しみが続きましたが、そこそこ体系的に知識突っ込めたような気がします。 Perl Advent Calendar 2011 Test Trackとか,tokuhiromさんのPerl テスティングハンドブック読んだりしましたし、 Perlだけじゃなくてユニットテスト全般の話をしたかったので、Junit実践入門読んだり、レガシーコード改善ガイドとか、 The RSpec Book読んだりしました。 そんな中、Perlでユニットテスト書くのってどうするのが最強なんだ？って言う疑問がすごいあって、 Test::Classが最強なんじゃないかと思ったりしたのですが、
PerlでHTTP API叩く開発する時モック的なのをサーバ立てずにやってみるテスト - As a Futurist...
最近 HTTP API 期なわけで、なんでもかんでも API サーバ作って叩き合えば、疎結合だし API サーバの実装は好きにやればいいしいい感じだよねーと思ってるわけです。ビジネスロジックだけじゃなくて、サーバ管理みたいなバックエンド業務も、なんでも MySQL にデータ入れて SQL というインタフェースでみんな叩けばいいよねみたいなのはいい加減やめたい。それ HTTP でいいやん！ で、色々サーバ書いたりとかしてみてるんですが、開発してるときに API 叩かれる側がまだできてないと叩く側を開発できなくてだるいなーとか、クローズドな API 使ってると公開とかするときあれだなーと思ってました。 僕が書くようなレベルって psgi ファイル 1 枚とかでモックだけだったら簡単にかけるので、それをローカルの適当なポートで起動しといて、とかでもいんだけど、もうちょっとかっこよくやりたかった。
Harriet ー テストのときつかうにデーモンの取扱を簡単にするためのフレームワーク - tokuhirom's blog
https://github.com/tokuhirom/Harriet/https://metacpan.org/module/TOKUHIROM/Harriet-0.01/lib/Harriet.pmテストのときにつかう mysqld, memcached, stf, groonga あたりのデーモンを、.t 単位で起動していては遅くてかなわない。かといって、あらかじめ起動させておくというのも。。 というわけで prove のプラグインとしてよしなにする、みたいなのをがんばってかく、というような試みがおこなわれてきたわけですが、どうもめんどくさい。 なんか適当にやったらうまくうごく、っていうかんじのカジュアルなツールがほしいな、なんておもったりするわけですよ そこで、Harriet ってのをつくってみました。 なんかこう、t/harriet/mysqld.pl っていうファイル名でこん
Coveralls + Perl - naoyaのはてなダイアリー
Coveralls は Github に置いているソースコードのテストカバレッジを git push の度に調査して報告してくれるクラウドサービス。「カバー率100%を維持したいなら継続的インテグレーション (CI) のレポーティングにテストカバレッジも含めちゃえばいいじゃない」という貴族向けのサービスです。いえ、貴族はフィクションです。 こんな感じでモダンなデザインで色々教えてくれる。各行が何回テストされたかみたいな詳細なレポーティングもある。 Travis CI と同じく Github の README なんかに貼り付けるバッジがあります。というか Travis CI なんかのCIツールと連携して Coveralls にレポートを投げるのが前提になっているようです。 つい最近 プロトタイプ開発用のRailsプラグイン「Chanko」を2.0.0にアップデートしました - クックパッド開
Devel::Cover
NAME Devel::Cover - Code coverage metrics for Perl VERSION version 1.44 SYNOPSIS To get coverage for an uninstalled module: cover -test or cover -delete HARNESS_PERL_SWITCHES=-MDevel::Cover make test cover or if you are using dzil (Dist::Zilla) and have installed Dist::Zilla::App::Command::cover: dzil cover To get coverage for an uninstalled module which uses Module::Build (0.26 or later): ./Build
mixiエンジニアがおくるソーシャルアプリ開発実践講座：第3回 自動テストと継続的インテグレーションを既存プロジェクトへ導入しよう｜gihyo.jp … 技術評論社
はじめに はじめまして。（株）ミクシィの加藤和良です。2008年度に入社し、2011年1月からはシステム本部 技術部に所属しています。技術部は、日記やコミュニティといった特定のサービスに紐づかない、mixi全体を裏から支える部署です。「支える」ための方法は、実際のサービスの一部として動作する共通基盤から、開発効率を上げるために社内で動作しているものまで、多岐にわたります。 mixiでは、ここ数年で自動テストの導入が急速に進みました。図1は、mixiのソースツリーにおけるコードと、そのテストコードの毎月1日のバイト数をグラフにしたものです。2008年の頭には少なかったテストが急速に増え、今年の5月にはコード量をも追い越しているのがわかります。 携帯電話向けmixiである「mixiモバイル」の開始が2004年、mixiニュースが2006年ですから、2008年当時のmixiも、それなりに大き
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ちょっと他言語に行ったら例えば RSpec にハマった人のために - Articles Advent Calendar 2011 Test
GitHub - lestrrat-p5/Geest: Port of Kage
full test also want to end within 50ms
GitHub - moznion/App--WithSound: Execute the command with sound
GitHub - onishi/perl5-devel-kytprof: Devel::KYTProf - Simple Perl code profiler