タグ

testingに関するsfujiwaraのブックマーク (34)

  • 個人開発してるWebサービスの API のシナリオテストに runn を使ってみたけど、とてもよかった - えいのうにっき

    個人開発してるWebサービス」というのは Pixela のことで、runn とは @k1loW さんが開発しているオペレーション自動化ツール/パッケージです。 pixe.la github.com Pixela は、そのユーザーインターフェースとして基的に Web API のみを提供しているサービスで(サービスを利用するための各種操作は基的にすべて Web API に対する HTTP リクエストによって行う必要がある)、現在そのローンチから6年目を迎えるサービスです。 blog.a-know.me ありがたいことに、世界中のユーザー(特に、プログラミング初学者の方によくご利用いただいているようです)に継続的に使っていただけているサービスになっており、登録ユーザー数はもうすぐ7万人に到達しようとしているところです。開発・メンテナンスに係る私の人件費を除けば、黒字運営を続けることもできて

    個人開発してるWebサービスの API のシナリオテストに runn を使ってみたけど、とてもよかった - えいのうにっき
  • Goのテーブル駆動テストではテストケースの定義位置を知りたいのでライブラリを書いた - 詩と創作・思索のひろば

    Go言語でテストを書く際のベストプラクティスとして、テーブル駆動テスト(Table dirven tests) というのが推奨されている。ようはデータとふるまいを分離しましょうという話で、正直わざわざ名前をつけるようなものでもなかろうという気持ちもないではないが、まあ話がはやくていいね。 けどみんなほんとにこれで満足してるの? と疑問に思うところはある。テストが落ちたときに表示される行番号がテストケースによらず一定で、どのテストが落ちたのかを探すのに一手間かかってしまう。 たとえば以下のコードをテストする際、 package eg import "testing" func TestExample(t *testing.T) { testcases := []struct { name string a, b int sum int }{ {"1+1", 1, 1, 99}, {"2+2"

    Goのテーブル駆動テストではテストケースの定義位置を知りたいのでライブラリを書いた - 詩と創作・思索のひろば
    sfujiwara
    sfujiwara 2023/10/12
    すごいべんり
  • ゲームにおけるA/Bテストについて - KAYAC Engineers' Blog

    こんにちは。技術部平山です。 今回は、ゲームにおけるA/Bテスト について論じます。 「論じます」で始めたことで察しがつくかとも思いますが、今回はブログではありません。 媒体はブログですが、ブログの容量ではない代物になっております。3.5万字(115KB)超えです。 ゲームにおけるA/Bテストについて、実施の方法や問題点、 倫理的側面に至るまで幅広く書き連ねてみました。 読んで欲しいのはどちらかと言えば同僚なのですが、 そういう時にはまず社外に出してしまった方が良いものですので、 ブログにしてしまいます。 比較的同業の方が読むことを想定しているため、 図表を用いてわかりやすくすることはしておりません。 これを書いた人間は何者か 技術的な問題の前に ゲームにおいても構図は全く同じ A/Bテストが可能である条件 A/Bテストの手続きを概観する 振り分け アプリ内振り分けの場合 Firebase

    ゲームにおけるA/Bテストについて - KAYAC Engineers' Blog
    sfujiwara
    sfujiwara 2023/02/13
    大作だ…面白かった
  • 響け♪ eupho ニアム - KAYAC Engineers' Blog

    ※ この記事は Tech KAYAC Advent Calendar 2016 14日目の記事になります こんにちは、劇場版でガルパンにどハマりして映画なんて全然観ない人間だったのに気づいたらほぼ毎週立川や幕張新都心にガルパン劇場版観に行って気づいたらこの一年で50回以上観てたりしてTV版一挙オールナイトも観に行ったりして、果ては大洗に行ってクイズラリーとか参加して海鮮丼べたりギネス飲んだりギネス飲んだお店にあんこう祭りでテンション上がって買ってしまったフィギュアを忘れてきたりしてる(これ書いてる時点でまだ預かってもらってる迷惑な)超絶にわかガルパンおじさんの瀬戸です。気づいたら会社の机の上もカオスになってきました。 ガルパンはいいぞ テスト遅い問題 アプリ開発しているとテストは書くわけですが、開発が進み2年も運用しているとテストの数が増えてきて当然のことながら少しずつテストの時間が延び

    響け♪ eupho ニアム - KAYAC Engineers' Blog
  • 今年テストで頑張ったことまとめ - KAYAC Engineers' Blog

    この記事は tech.kayac.com Advent Calendar 2015 2日目です。 こんにちは、最近よく過激派と呼ばれている穏健派のshogo82148です。 今年一年、安心して開発ができるようテストに特に力を入れてきました。 そこで今年テストでおこなった取り組みを振り返ってみようと思います。 残念ながらGoではなくPerlのテストのお話です。 テストをとにかく速くする! 最初に手をつけたのはテストのスピードです。 まず全部のテストが通るようリファクタリングをしてから機能追加というスタイルで開発していたんですが、 全部のテストが終わるまでに10分20分もかかっていてはいつまでたっても機能追加に着手できません。 Jenkins EC2 Plugin とりあえずマシンパワーで解決だ!ということでEC2でマシンパワーの高いインスタンスを使いました。 Spot Instanceを必要

    今年テストで頑張ったことまとめ - KAYAC Engineers' Blog
    sfujiwara
    sfujiwara 2015/12/02
    すごい頑張ってる
  • Test::mysqld::Multiというモジュールを書いてみた

    Test::mysqldのインスタンスを一度に大量に作りたい人向けに Test::mysqld::Multiというモジュールを書いてみました。 2016/12/22追記: Test::mysqld::MultiはTest::mysqld 0.20 の一部として取り込まれました (p5-Test::mysqld#13)。 APIは少し変わっているので、詳しくはPODを参照してください。 合わせてApp::Prove::Plugin::MySQLPool 0.06 より、 記事で紹介した高速化が利用できます。 背景 先日Jenkins EC2 Plugin で Spot Instance を使ってテストを回すというのを、 tkuchikiさんにお願いして僕の関わっているプロジェクトでやっていただきました。 CPUのたくさん載ったインスタンスを安く使えるようになったので、 8並列で動いてたテス

  • ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々

    あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか?もしくはコードカバレッジだけにとらわれすぎていないでしょうか? 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に番用の設定ファイルを使うことはないため、番用の設定ファ

    ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
  • jenkins + prove で失敗したテストを並列しないで再テストする試み - soh335 memo

    深淵な理由で(特に並列度をあげると)たまに落ちてしまうテストがあって、その度にあぁこれはたまに落ちちゃうやつなんですよねみたいな会話するのもいかがかと思っていた。 なので、落ちたテストがあった場合に並列しないで再度 prove してあげてそれでも落ちたらレポートするがいいかなぁと思ったのでこういう感じでやってみた。 JUNIT_NAME_MANGLE=none JUNIT_OUTPUT_FILE=output.xml prove -lvr -j5 --harness TAP::Harness::JUnit t JUNIT_OUTPUT_FILE は TAP::Harness::JUnit が生成する xml を指定する環境変数。 JUNIT_NAME_MANGLE に関しては TAP::Harness::JUnit - search.cpan.org に説明がある。 デフォルトだと hud

    jenkins + prove で失敗したテストを並列しないで再テストする試み - soh335 memo
  • LWP::UserAgent と LWP::Protocol::PSGI でテストを書くと楽できる話 - punitan (a.k.a. punytan) のメモ

    Plack::Test + HTTP::Request::Common 世の中には Plack::Test + HTTP::Request::Common という方法もあるが、この場合ブラウザを模したようなテストを書くと意外にも破綻しやすい。とりわけセッション周りの挙動が必須になると大変な手間になる。 LWP::UserAgent + LWP::Protocol::PSGI 最近は LWP::UserAgent + LWP::Protocol::PSGI で楽をするような方法で書くようにしている。ユーザー寄りのテスト(ログイン後の処理やCSRF対策用のトークンが必須等)をわりと楽に書ける点がメリット。 subtest と scope のメリットも享受できる /zento+/ 方式が見通し良く出来そう。*1 サンプル Some::Middleware::CSRFDefenderのテストを書く

    LWP::UserAgent と LWP::Protocol::PSGI でテストを書くと楽できる話 - punitan (a.k.a. punytan) のメモ
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • Ukigumo - Yet another continuous testing tool - tokuhirom's blog

    Ukigumo - Yet another continuous testing tool http://github.com/ukigumo/ なんか、お気軽につかえて、カスタマイズが容易で、お気楽な continuous testing を support する tool がほしかったので、ちょろっとかいた。 ターゲットは自社サービスの web アプリケーションです。 ベーシックなクラサバ構成となっています。サーバー側は簡単な Web UI と、RPC を提供しているだけで、ごくシンプルです。サーバー側とクライアント側には依存関係はありません。クライアント側はプラガブルな構成となっていて、誰でも簡単にいじれます。 クライアント側は Plagger 風にしようとおもったんですけど、Plagger 風にするといかんせんおおげさになりすぎるので、ライブラリとしての提供にとどめました。べろっと

  • Test::QUnit - mozrepl経由でコマンドラインからJavaScriptのテストを実行する - 愛と勇気と缶ビール

    マクラ - JavaScriptのテストについて テストのないコードはコードではなく、テストを書かないプログラマはプログラマではなく、テスティングフレームワークのない言語は言語と呼ぶに値しない。と以上のような偉そうなことを言う資格は全くないし狂信的でもない僕ですが、少なくともまともに動くコードであることを証明するために、人並みにはテストを書きます。 それでまあ、最近JavaScriptばかり書いてるのですが、JavaScriptのテスティングフレームワークって大体以下のようなものに分かれると思っています。 ブラウザ上で動かすことを前提としたもの(JsUnit, QUnitなど) RhinoやSpiderMonkeyなど、ブラウザから独立したJavaScriptエンジンで実行することを前提としたもの(JsUnit, QUnit-TAPなど) 2. に加え、env.js(http://www.

    Test::QUnit - mozrepl経由でコマンドラインからJavaScriptのテストを実行する - 愛と勇気と缶ビール
  • Kazuho@Cybozu Labs: テストケースの実行にあわせて Apache を起動・終了する方法

    ウェブアプリケーションやライブラリの結合テストを行う段階になると、実際に Apache を起動してテストを実行したくなります。しかし、そのためにいちいち Apache の設定ファイルを修正して httpd を再起動して、とやっていては面倒です。特に複数のプログラムを同時に開発していると、あっちをテストしたらこっちが動かなくなって… なんてなったりして嫌気がさしてきます。 そこで、テストを実行する際に、環境毎に異なる以下のような問題を吸収しつつ、テスト専用に設定された Apache を自動的に起動終了してくれる Perl モジュール:Test::Httpd::Apache2 を書きました。 環境によって、インストールパスが違う (/usr/local/apache/bin だったり /usr/sbin だったり) 環境によって LoadModule の要不要や、ロードするパスが違う 環境によ

  • いまからでも間に合う開発者テスト - mixi engineer blog

    はじめまして。開発部じゃない加藤和良です。 最近、mixi では Buildbot をつかった継続的インテグレーションをはじめています。安定版の mixi のソースコードにコミットすると Buildbot がそれを検知し、自動的にテストが走るようになりました。 ここでの「テスト」は Test::Simple や prove(1) をつかった、Perl でかかれた開発者テストを指しています。mixi の開発者テストをとりまく環境は、ここ数年でかなり改善されました。今回はその歩みをふりかえりながら、テストの無いコードベースをどこからどうやって変えていったかという話をしたいと思います。 開発環境 はじめに、前提となる mixi の開発環境について説明します。mixi では複数人の開発者がひとつのマシンで作業を行います。それぞれの開発者は、あらかじめ割り当てられたポートで Apache を起動し、

    いまからでも間に合う開発者テスト - mixi engineer blog
  • 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

  • https://blog.8-p.info/2009/05/test-apache2-released

  • Selenium Auto Exec Server(AES)

    Japanese / English Selenium Auto Exec Server(以降 Selenium AES)は、Seleniumによる継続的なリグレッションテストを行うためのツールです。 プロジェクトにおけるテストの手助けとなることを目標としています。 Selenium AESを使えば、SeleniumのHTML形式のテストを毎日決まった時間に実行し、その結果をメールで送信するといったことが簡単に行えます。 他にもSeleniumを使ったリグレッションテストを手助けするための様々な機能が提供されます。 Selenium AESは、Selenium RCを拡張することにより、実現しています。 また、Selenium RCのHTMLSuiteに対する使い勝手を向上させたツールとして、Selenium HTMLSuite Extensionというものも公開しており、Selenium

  • メールをどこにも送らずHTMLで保存するSMTPサーバ mocksmtpd.rb - こせきの技術日記

    (2014/6/3 追記) MailCatcher がおすすめです。 MailCatcher (2008/11/4追記) gem版も作ってみました。 RubyでSMTPサーバを作る(1) - バリケンのRuby日記 - Rubyist id:muscovyduckさんの(素晴らしい)記事を参考に、ちょっとだけ手を加えて開発用のSMTPサーバ mocksmtpd.rb を作成しました。メールを外に出さずにHTMLで保存する単純なSMTPサーバです。 これを使うと、Seleniumでメールのテストが簡単にできるようになります。ユーザ登録時にURLをメールで送信して人確認とか。間にメールが挟まってもテストがつながります。 使い方 # コンソールで実行 mocksmtpd.rb # デーモンとして実行 mocksmtpd.rb -d # デーモンを停止 mocksmtpd.rb stop他にオプ

    メールをどこにも送らずHTMLで保存するSMTPサーバ mocksmtpd.rb - こせきの技術日記
  • つくるぶガイドブログ: Test::WWW::Declareを使って宣言的にWebアプリのテストを作成

    こんにちは。 つくるぶガイドブログ Perl担当の西山です。 Perlカテゴリーのエントリーでは、CPAN(世界中のPerlプログラマーが作成しているライブラリを集約したアーカイブ)に登録されているモジュールの中から、便利だったりコードが格好良かったり、Perlならではの魅力を持っているようなモジュールを取り上げていこうと思っています。 よろしくお願いします! Test::WWW::Declareモジュールについて というわけで、一発目は Test::WWW::Declare モジュールをご紹介します。 今年の春のYAPC::AsiaでJesse Vincent氏が 「Abusing Domain Specific Languages for Fun and Profit」 というセッションで発表していたり、最近では 宮川達彦さんのWeb::Scraperのスライド に "integ