はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
いまからでも間に合う開発者テスト - mixi engineer blog
はじめまして。開発部じゃない加藤和良です。 最近、mixi では Buildbot をつかった継続的インテグレーションをはじめています。安定版の mixi のソースコードにコミットすると Buildbot がそれを検知し、自動的にテストが走るようになりました。 ここでの「テスト」は Test::Simple や prove(1) をつかった、Perl でかかれた開発者テストを指しています。mixi の開発者テストをとりまく環境は、ここ数年でかなり改善されました。今回はその歩みをふりかえりながら、テストの無いコードベースをどこからどうやって変えていったかという話をしたいと思います。 開発環境 はじめに、前提となる mixi の開発環境について説明します。mixi では複数人の開発者がひとつのマシンで作業を行います。それぞれの開発者は、あらかじめ割り当てられたポートで Apache を起動し、
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
ドキュメントとテストコードつきの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
Perl tests in Hudson via JUnit - The Player Of Games
Perl tests in Hudson I'm willing to automate the unit testing of my Perl modules, by plugging them into Hudson. Hudson is a continuous integration server, it "monitors executions of repeated jobs, such as building a software project or jobs run by cron". It works well, is extensible, and looks good. So, The easiest way to do that is have Hudson to execute the module test suite, and look at the out
no_planはずるい？ | taro-nishinoの日記 | スラド
最近のCPANでは、テストスクリプトにテスト数を宣言しない流儀が定着して来ましたが、それをAdam Kennedy氏は″The unfortunate demise of the plan″で嘆いておられます。Test::Moreにdone_testingが追加されたことも、テスト数を宣言しないことに拍車を掛けたようですが、私個人はMatt S. Trout氏のエッセイ″A cunning no_plan?″を読んで、始めてdone_testingが追加されたことを知りました。テスト数を宣言しないことに両論があるのは知っていますが、私は宣言しない方に肩入れしたいと思います。理由は簡単です。要は数えるのも面倒くさいからです。 以下に″A cunning no_plan?″の私訳を載せておきます。なお、エッセイの最後部分には氏の著書に関する記述があるのですが、それは本題とは関係が無いと思いまし
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接続を
HTTP::Engineでテスト : As Sloth As Possible
そう言えばこないだのうどん屋のコードは一切テストを書かなかったけど、それはよろしく無い、まったくもって主義に反するし、RubyのときはちゃんとSpec書いたのにPerlのときは書かないだとかふざけてる、と思ったのでテストも書いてみることにした。 さてテストだけど、HTTP::Engineにはちゃんとテスト用のインターフェースが用意されている。あと、テストリクエストを生成するモジュールもある。なんだ、じゃあ話は簡単だ。 interface => { module => 'Test' } でengineを作る HTTP::Engine::Test::Requestでrequestを作る engineのrunメソッドにテストリクエストを投げてやる 返ってきたレスポンスをチェックする ってことですね、わかります。 まずは素直に書いてみる コード量少ないのではっつけちゃおう。Udon::AppにGE
pgTAP: Unit Testing for PostgreSQL
pgTAP is a suite of database functions that make it easy to write TAP-emitting unit tests in psql scripts or xUnit-style test functions. The TAP output is suitable for harvesting, analysis, and reporting by a TAP harness, such as those used in Perl applications. Why would you want to unit test your database? Well, there are a couple of scenarios in which it can be useful. Application Development S
tips - Webサーバーの負荷テストならまずab : 404 Blog Not Found
2009年05月13日16:45 カテゴリTips tips - Webサーバーの負荷テストならまずab だめじゃん。 WEBアプリ開発に便利な機能＆負荷テストツール集:phpspot開発日誌 abがないじゃん。 abとは何かというと、apacheに標準でついてくる負荷テストツールの名前。apacheが入っている環境であれば、まず間違いなく入っているはず。 引数なしだと、help表示。 ~% abab: wrong number of arguments Usage: ab [options] [http[s]://]hostname[:port]/path Options are: -n requests Number of requests to perform -c concurrency Number of multiple requests to make -t timelimi
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
Test-Behaviour-Spec-0.01 を CPAN へ登録 - Tociyuki::Diary
Perl のテストで Behaviour Driven Development (BDD) して遊ぶためのモジュールを CPAN に登録しました。ご利用ください。 ⇒ http://search.cpan.org/~tociyuki/Test-Behaviour-Spec-0.02/ 0.01 の POD の使用例コードにセミコロンが一ヶ所抜けていたので、修正しました。コード本体は 0.01 と同じです。 ⇒ http://search.cpan.org/~tociyuki/Test-Behaviour-Spec-0.01/ Test::Behaviour::Spec は、ふるまいを記述するための述語 describe、it、spec をサブルーチンとして使えるようにするだけで、いっさい Test::More 等への変更をおこないません。そのため、従来のどのようなテストにも、ふるまい記述を
Perl で、「なんちゃって Behavior Driven Development」 - Tociyuki::Diary
Ruby界では注目を集めてきた割に、Dave Astels が 2005 年に提唱した「A NEW LOOK AT TEST-DRIVEN DEVELOPMENT (日本語訳)」(原文pdf)による Behavior Driven Development (略して BDD)は、Perl 界ではスルーされているような気がしてなりません。 ことの本質はテストを何のために書くのかという姿勢にあり、ツールは従来のテストでも良いという割り切った感覚が Perl 使いにはあるからなのかもしれません。現実に、Ruby の BDD フレームワークの RSpec 熱い紹介記事にも、身も蓋もなく、そのように書いてあります。 ⇒ Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編) かくたに、もろはし著 FAQ:「RSpec っ
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
CatalystアプリをbuildbotでContinuous Integration - dann@catalyst - Catalystグループ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Unit Test Your Database
Test-Cukes-0.11 - A BBD test tool inspired by Cucumber - metacpan.org
https://www.func09.com/wordpress/archives/532
Happy Testing Perl 記事一覧 | gihyo.jp
