Fake is a new browser for Mac OS X that makes web automation simple. Fake allows you to drag discrete browser Actions into a graphical Workflow that can be run again and again without human interaction. The Fake Workflows you create can be saved, reopened, and shared. Inspired by Apple's Automator application, Fake looks like a combination of Safari and Automator that allows you to run (and re-run
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー みなさんテストしてますか？ Pythonには沢山の便利でステキなテストツールがあります。標準ライブラリに入っているunittestやアジャイルドキュメンテーションとも呼ばれるdoctestなど，標準の機能だけでもかなり強力なのですが，外部のツールを使うとより快適なテストライフが送れるのです。 python.orgにあるPython testing tools taxonomy(Python用テストツールのまとめ)というページがあり，ここに有益な情報が集まっているので例によって超訳してみました(ユニットテスト関連のみ)。 ツール カテゴリ 作者 ツールが含まれるフレームワークなど 特徴
計画的に実行するのはよいことですが 前回も紹介したように、Test Anything Protocolでは「これから10個のテストを実行します」と宣言する場合はこのように書くことになっていました。 use strict; print "1..10\n"; # 宣言部 for (1..10) { print "ok $_\n"; } このような宣言部の存在は、テスト結果をパースして分析するTest::Harnessのようなツールにとっては非常に便利なものですが、たとえば環境によってテストの数がかわるとき、あるいはテストファイルが非常に長くなってきたとき、はたまた多くの人が平行してファイルやテストの追加作業をしているため最後にマージするまでテストの数がわからないとき、事前にテストの数を把握していなければならないというのは、大きな制約にもなりえます。 単純そうに見えるTest Anything
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
Test::ContinuousでGrowlにtest完了通知させるようにしてみる - すぎゃーんメモで、testが終わるたびにGrowlで結果を教えてくれるのが便利だなーと思って、でもそれを使わない普通のproveコマンドの場合も結果を通知して欲しい！！ ということで作ってみた。 GitHub - sugyan/App-Prove-Plugin-Growl: proveのGrowl通知プラグイン proveコマンドは、"App::Prove::Plugin::ほげほげ"というモジュールがあれば prove -Pほげほげと指定することでプラグインを読み込んで実行できるらしい。ので、こんな名前になります。 こんなカンジで、proveの結果がGrowlで通知されるようになります。 Log::Dispatch::DesktopNotificationを使っているのだけど、Mac以外の環境だと動か
Test Anything Protocol Perlは非常にテストを重視している言語です。連載第14回ではPerl本体のテスト数がどのように推移してきたかを、また連載第24回ではCPANモジュールの品質保証に大きな役割を果たしてきたCPANTSについて簡単に紹介しましたが、Perlとテストのつながりはそれだけではありません。CPANにはTestを名前に含むディストリビューションが500以上もあがっていますし（これは全ディストリビューション数の約2.5％にあたります）、Perlで標準的に使われているテスト形式はTest Anything Protocol (TAP)という名前を得て多くの言語に移植され、2008年からはIETFの標準化を目指した活動も始まっています――というと何やらすごいプロトコルのように聞こえるかもしれませんが、Test Anything Protocolというのは要
はじめまして。開発部じゃない加藤和良です。 最近、mixi では Buildbot をつかった継続的インテグレーションをはじめています。安定版の mixi のソースコードにコミットすると Buildbot がそれを検知し、自動的にテストが走るようになりました。 ここでの「テスト」は Test::Simple や prove(1) をつかった、Perl でかかれた開発者テストを指しています。mixi の開発者テストをとりまく環境は、ここ数年でかなり改善されました。今回はその歩みをふりかえりながら、テストの無いコードベースをどこからどうやって変えていったかという話をしたいと思います。 開発環境 はじめに、前提となる mixi の開発環境について説明します。mixi では複数人の開発者がひとつのマシンで作業を行います。それぞれの開発者は、あらかじめ割り当てられたポートで Apache を起動し、
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー テストをなかなか始められない人が多いように思います。 テストの効用として，コードのクオリティが高くなったりメンテナンス性がよくなったり，といったことはよく言われることです。また，テストのことを考えな がらコードを書くようになるので事前に十分な思考実験をするクセがついて，行き当たりばったりの開発をしなくなります。テストしやすいコードを書くように なるので，コードのモジュール性が高くなり，結果として再利用性の高い高品質なコードを書けるようになる，という利点もあります。 全部分かっていても，テストは面倒だし，テストを書くためには予備知識も必要なので，そんなことがハードルになってなかなかテスト
Google App Engine SDK for Python には、単体テスト用に各サービスのスタブが提供されています。このスタブと unittest を使えば、ローカル環境で GAE 用アプリの単体テストが可能です。 GAE/Python で unittest を使って、単体テストを行うサンプルは次の通り。 #!/usr/bin/env python #encoding: utf-8 import os import sys # 環境設定 # これをしないと GAE のモジュールをインポートできない。 # テスト対象のクラスも同様。 # ここを自分の環境に合わせて書き変えます GAE_HOME = 'Google App Engine SDK ディレクトリのパス' PROJECT_HOME = 'アプリケーションのルートディレクトリのパス' # テストで使う GAE のモジュールのパ
Perl で、あるコードが標準エラー出力に吐き出した内容をテストしたい場面がありました。 自分でまず思いついたのは STDERR を dup して保存しておいて、ファイルにリダイレクトして、元に戻して、というやりかた。これはこれで動くのですが面倒。こういう場合は Test::Output (や miyagawa さんに教えてもらった Capture::Tiny) が便利です。 Test::Output はこんな感じ。 std(out|err)_(is|isnt|like) といったテスト関数が使えるようになります。 use Test::Output; use Test::More; stderr_is { # STDERR になにか出力するコード } "STDERRの内容", "description"; stdout_like { # code } qr/regexp/, "descri
jQueryでユニットテストをおこなう - QUnitとは 高機能・軽量のJavaScriptフレームワークで、デベロッパにも人気の高いjQuery。そのjQueryをベースとしたテストスイートに「QUnit」がある。 QUnitはJohn Resig氏とJorn Zaefferer氏が中心となって開発をおこなっているユニットテスティングフレームワーク。デベロッパはQUnitを使うことで、jQueryを使ったJavaScriptコードを書くように、簡単にテストを記述できるようになる。同ライブラリはjQueryと同じく、The MIT LicenseとGNU GENERAL PUBLIC LICENSE Version 2のもとで公開されている。 去る9月29日(米国時間)、開発者であるJohn Resig氏はTwitter上で次の3点をアナウンスした。 QUnitはjQueryに依存した実
wwはRuby/Sinatra製のオープンソース・ソフトウェア。Web APIを使った開発の場合、自動化したテストをいかに行うかが問題になる。特にWeb APIのように他サービスのリソースを使う場合、テストで過剰アクセスするとブロックされてしまう危険もある。 外部サービスを使った開発で利用 それを回避するにはテスト用に別途サーバを用意するのが良い。設定ファイルでテスト時や開発時にはローカルのサーバにデータを飛ばすのだ。柔軟にレスポンスデータを返すのにwwが面白そうだ。wwはSinatraで作られたダミーのWebサーバだ。 wwはレスポンスデータを設定したスクリプトを使ってサーバを立ち上げる。SinatraなのでURLの設計は容易で、レスポンスデータの設定も簡単だ。ユニットテストとも連携でき、自動的に立ち上がってテストができる。テストケースごとにサーバがリセットされる機能もある。 リクエスト
テストとおらなくても動いてたのでスルーしてたけど、MENTAをmake testしてみたらきれいにパスしたので、加筆してみた。 MacでYacafiをmake testすると、以下の状態になってた。 t/00_compile........ok xt/01_podspell......sh: spell: command not found Died at /opt/local/lib/perl5/site_perl/5.8.9/Test/Spelling.pm line 54. # Looks like your test exited with 127 before it could output anything. xt/01_podspell...... Dubious, test returned 127 (wstat 32512, 0x7f00) Failed 1/1 subt
_ [Program] Test::Spelling make test の時に pod ドキュメントのしペルチェックをしてくれるツール. 前ちょっと試したときに動かなくてほっぽってたけどまたトライ. でもやっぱりうまくうごかせず；； でも miyagawa さんや tokuhirom さんに教わって動作成功♪ うちの環境だと spell がないから set_spell_cmd("ispell") とかしてたのですけれど, aspell だと set_spell_cmd("aspell list"), ispell だと set_spell_cmd("ispell -l") で動く模様. pod にあった aspell -l はうちのとこではだめした. うちのの完成版をさらしてみます〜. stopwords (例外語句) は, pod のなかで =for stopwords plok P
はじめまして。 最近Perlを始めたmyfinderです。 ほかの方が書いたCPANモジュールを紹介したりそれらを使ったTipsを書くCasual Trackということで、今回はテストに関連するモジュールについて書きます。 プログラムの「テスト」 テストを書くというのはデンタルフロスを使うようなもので、誰もが良いことだといいつつ、実際には軽視されがちだ。 なんて言われることもありますが、実際テストがないとプログラムの改修とか引き継ぎとかが非常に大変になりがちです。 また、CPANにアップされているモジュールの中には、モジュール本体よりもテストコードの量の方が多いものも多々あります。 なのでプログラムの質を保証したり、内容を的確に伝達するにはテストが欠かせないものであることは間違いないと思います。 早速使ってみる 例えば消費税の計算をしてくれるConsumptionTax::JPというモジュ
tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql
【GoogleTest Assertions まとめ】 ↓のWikiから、Assertionを和約（適当）してまとめてみる。 http://code.google.com/p/googletest/wiki/GoogleTestPrimer http://code.google.com/p/googletest/wiki/GoogleTestAdvancedGuide 注）勢いで書いたので、自分に都合の良い所だけ抽出、意訳しています。 あと、実はバージョン1.2.0の時に訳したもののコピペです。 基本 Fatal assertionNonfatal assertionVerifiesASSERT_TRUE(condition);EXPECT_TRUE(condition);condition is trueASSERT_FALSE(condition);EXPECT_FALSE(condi
[GoogleTest1.3.0を使ってみた] Google C++ Testing Framework http://code.google.com/p/googletest/ Googleのテストフレームワーク「GoogleTest」に去年の年末くらいから興味を持ち始めて使ってみた。 かなりいけてるのに日本語解説が少ないので、やった事をいろいろと書き出す。 なにができるのか・マルチプラットフォーム対応 Windows（VC）、Cygwin（gcc）、Linux、MacOS、WindowsCE、Symbian・・・ ・テストコードの自動発見 RUN_ALL_TESTS() で勝手にTEST(Hoge, hoge)と書いたコードを探索して実行してくれる （もちろん任意のテストだけ実行する、しないのオプションもあり） ・豊富なAssertion 失敗（ASSERT）と警告（EXPECT）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
