⚠️ This project is no longer maintained Active development has been moved to Device Farmer
最近は担当システムが平和だけど俺が平和じゃない。疲れてる。忘年会の連チャンもきっついトシになっちまった。会社の制度で1週間くらい休みがとれるので、一人で温泉とスノボと開発合宿でもしに北海道にでも行こうかなって思ってる。1月か2月くらいに。 えーと、担当しているサービスにserverspecを導入した。それにあたってテスト項目を考えたので軽くまとめる。もちろんserverspec導入前もサーバ構築後は動作確認というか、テストらしいことはしていたっちゃしていたんだけど、テスト項目をまともに考えたのはこれが初めてかもしれない。serverspecのバージョンは0.13.2である。Rubyは2.0.0。 0. 環境 下記のような環境に導入した。ありふれた構成だと思う。60台くらいの規模。DBはマスタ3台に分割されていて、それぞれにスレーブがn台ぶらさがっている。LBの箱は二つあるが、物理的には1台
(注記:6/9、いただいた翻訳フィードバックを元に記事を修正いたしました。) 今回の記事は毎秒300万ものリクエストを処理できるほど強力で高性能なWebクラスタの構築についてのパート1になります。まず初めに、あまり多くはありませんが、私がこれまで使用したことのあるロードジェネレータツールをいくつか紹介します。私のようにてこずって時間をかけてしまわないよう、今回の記事が理解の手助けになれば幸いです。 ロードジェネレータはテストを目的とした数種類のトラフィックを発生させるプログラムです。それによって高負荷においてサーバがどのように動いているか、そのサーバの弱点はどこなのか、などが見えてきます。負荷テストを通じてサーバの限界を知ることは、サーバのレジリエンシーを測定する最適な方法であり、あらゆる問題に対する準備の手助けにもなります。 ロードジェネレータツール 負荷テストをする際に頭に入れておくべ
「今までテストを書いたことがないから、そろそろテストを書かなくては・・・」という、PHPUnitもテストのこともまだ知らないプログラマにとって、一番最初に欲しいのは「何から始めたらよいのか」を知るためのガイドです。 本書は、PHPUnitを使ったテストの書き方を、短時間で知るための小冊子です。これだけ読めば、PHPUnitでテストを書いていけるようになります。 本書が特徴的なのは、ユニットテストの形式的な書き方だけを単純に説明した本ではないということです。本書では、PHPUnitによるテストを、オブジェクト指向の原則に沿った、良いコードへリファクタリングしていくための道具、と位置づけています。その流れに沿って、必要最低限の基礎知識や、実際にありそうなサンプルコードで使い方が説明されています。モック(テストダブル)を使ったテスト、フィクスチャを使ったテスト、APIのテストといった対象ごとのP
2015年2月24日 ヒカ☆ラボ発表資料 Webアプリケーション負荷試験実践入門 ■スライドの目的 負荷試験の重要性を認識して頂く 意味のある負荷試験を最短距離で行うための“段取り”を持ち帰って頂く 内容的には、主にAWS上のLAMP構成のシステムに対する負荷試験ですが、負荷試験ツールに依存しない全般的に通用する話を扱っています。Read less
JMeter使うのだるいなーと思ってたらruby-jmeterというRubyでテストプランを書けるツールがあった。知らなかった(迫真)。 典型的なRailsアプリのテストプラン そういう訳で典型的なRailsアプリのテストプランを書いてみたのがこちら。 ユーザーログインページでCSRFトークンを取得し、常にHTTPヘッダにつけるようにする ユーザーログイン情報をクッキーに保存 といった典型的な処理を盛り込んでいます。あとはREADME.mdを読んでもらえれば大体の書き方が把握できるかと思います。 ちなみに、# Debugというコメントの下2行をコメントアウトしてもらうと、JMeter上でデバッグ用の出力を表示することができます。テストプランが上手く動かないときに、リクエストヘッダやレスポンスを確認するのに便利です。 で、これをコマンドラインで ruby sample.jmx.rb && j
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
test-kitchenの使い方を調べたり検証していたりしたのですが、インスタンスを作成してプロビジョニングするのに結構時間がかかって暇なので、書いてみました。 test-kitchenについて test-kitchenとは、任意に作成したインスタンス上に環境を構築し、その結果の検証が可能なツールです。インスタンスを作成するためのドライバはデフォルトでvagrantが選択されますが、vagrant以外、例えばkitchen-dockerを使えばdocker上でテストを行うことも可能です。 test-kitchen https://github.com/test-kitchen/test-kitchen.git 初期設定 〜 インスタンスの構築 実際にtest-kitchenとserverspecを使ったchef-repoのテストをやってみます。 test-kitchenの挙動 test-k
更新:v1.2.2.devに対応。 Chef Inc. (旧Opscode)のtest-kitchenについて、テストのライフサイクルとサブコマンドの使い方を説明する。 1.2系について。 Test-Kitchenヘルプ まずはkitchenコマンドを叩くとヘルプが表示される。 $ kitchen Commands: kitchen console # Kitchen Console! kitchen converge [INSTANCE|REGEXP|all] # Change instance state to converge. Use a provisioner to configure one or more instances kitchen create [INSTANCE|REGEXP|all] # Change instance state to create. Star
テストの書き方 基本 今までのTest::Unitと変わらないので,classで書く.ただ,昔のTest::Unitとは違い,TestCase毎に呼ばれるstartupやshutdownなどが増えている. require 'test/unit' class TestSample < Test::Unit::TestCase class << self # テスト群の実行前に呼ばれる.変な初期化トリックがいらなくなる def startup p :_startup end # テスト群の実行後に呼ばれる def shutdown p :_shutdown end end # 毎回テスト実行前に呼ばれる def setup p :setup end # テストがpassedになっている場合に,テスト実行後に呼ばれる.テスト後の状態確認とかに使える def cleanup p :cleanup
Record HTTP interactions in your tests ...and replay them during future test runs for fast, deterministic and accurate tests. Disclaimer: Doing this in PHP is not as easy as in programming languages which support monkey patching – this project is not yet fully tested, so please use at your own risk! What? Instead of manually mocking API calls for your tests, record HTTP requests and replay them la
Cucumberって、仕様設計者の意図をプログラムによる自動テストにできる魔法です。 仕様設計者っていうのは、Rubyでのプログラミングが難しいけど、お客さまのニーズを理解して、それをドキュメントにできるハイパーな人です。プログラマにとっては神様です。 (でも、それがプログラマの徹夜の源なのだったりしますよね。実現が困難で意図が不明な仕様を必死で実装する感じですよね。だから、それをなんとかしなければ徹夜は解消できないと考えてみました。) Cucumberではプログラマ以外の人でも分かりやすい記述ができます。 でもね、どうせそのドキュメントを見るのはプログラマだけです。なので、生のCapybara APIで十分なのかもしれませんね。なので、ここではRSpecのfeature specを考察します。 from Feature spec on Relick : https://www.relis
Python製のWebアプリケーションの自動受け入れテストをしたくて、調べてみました。 Ruby界隈だと、最近ではCucumberに代わってTurnipというツールが流行っているみたいなので試してみました。 (c) .foto project 自動受け入れテスト用のライブラリ Rubyで自動受け入れテストをしようとすると、以下の3つの選択肢があるようです。 Cucumber テストケースを自然文で書けるため、非プログラマでも読みやすい。 Turnip Cucumberと似ているが、プレースホルダーを簡単に書ける点とRSpecの一部として使える点がメリット。 RSpecのfeature spec RSpec(+Capybara)で完結。非プログラマには読みにくい。 Cucumberは以前にも使ったことがあるので、今回はTurnipを選択してみました。詳しい説明は以下のページに譲ります。 Ru
The document defines a fib function that recursively calculates Fibonacci numbers and prints the 10th Fibonacci number. It then defines some unit tests for a Calculator class that test the add method by asserting the expected result. Finally, it defines some unit tests for a User class that test validating a user object.Read less
先ほどの記事の後に、色々いじっていて高速化の糸口が掴めそうだったのでメモ程度に書きます。 今回やったのは、setUpでテスト毎に毎回呼ばれる処理に重いものが入っていたら、setUpBeforeClassに移動させて速度の改善を計ってみました。 (テスト的に毎回呼ばなければいけないものもあると思うけど、一旦無視して計測) 一部、このメソッドは重い。ってのが分かっていて、それをsetUpで呼んでいる部分を修正していきました。 実行結果 /vendor/bin/phpunit PHPUnit 3.7.28 by Sebastian Bergmann. Configuration read from xx/phpunit.xml ............................................................... 63 / 612 ( 10%) .....
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く