前置き 先日BEAR.Sunday作者の koriym さん とSymfony勉強会でご一緒して話す機会があり、 echo を テストするにはどうしたいいのか？ HTTPレスポンスヘッダーに想定通りのものが出力されることを確認（header() 関数をテスト）するにはどうしたらいいのか？ ※ ここで言うテストとはユニットテストを書くということです という話をしました。 自分自身気づきもあったし、興味深かったので書くことにしました。 解説 まず、テスト対象であるHttpResponderというクラスについて見てみましょう。 プロダクトコード HttpResponderクラス <?php /** * This file is part of the *** package * * @license http://opensource.org/licenses/bsd-license.php B

こんにちは、井上です。 東急ハンズでは8月26日〜9/2にハンズメッセというセールを開催しました。今日はそれに向けて行った、ネットストアの負荷対策の内容を紹介したいと思います。 システムの負荷対策の取り組みとしては、長期にわたるシステムの改善と、直前の対応があるのですが、今回は直前の対応について紹介します。 （１）負荷試験準備 まずは負荷試験をするための準備を行いました。 ELBのPre-Warming申請 負荷試験を実施するにあたり、まずは負荷試験を実施する環境のELBの暖機運転（Pre-Warming)の申請を行いました。 ELBは急激なスパイクアクセス時にスケールするのに時間がかかるため、予めアクセス増加が分かっている場合には事前に申請しておきます。 下記のような内容をまとめて、AWSのサポートセンターより申請を行います。 ・ 予測されるピーク時のリクエスト数 (requests/秒

This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur

はじめに言っておきますと、テストは重要ですよ。テストしないなんてありえない。 でも、テストコードを書いて当たり前という昨今の論調には、同意できないのです。テスト熱中症になんて到底なれません。そう思うのは私だけではないようで、Rails の作者も書きまくればいいってものではないと言っています。 なぜ同意できないのか、理由を書き連ねて鬱憤を晴らすことにします。 コスト対効果が悪いから もうこれに尽きる。尽きすぎる。テスト書いてもほとんど不具合なんて見つからないです。 なぜって？　なぜでしょうね。知りませんが、ほとんど不具合ないんですもの。 typo の類はコンパイル時に修正されてますし。 コンパイル型言語じゃない？　コンパイル型言語使えばいいんじゃないですか :-p 難しいバグは見つけられないから テストコードでさらっとみつかる不具合はそもそも簡単・単純なものが多いです。 再現しやすければ、改

平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識

https://github.com/tddbc/TestingFrameworkMeeting で話した資料です。Read less

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに こんにちは、ヤフーメール エンジニアの小沼俊治です。 開発者の皆さんの中には、CIにユニットテストの自動化を導入して、日々開発されるプロダクトの品質維持に務めている方々も多いのではないでしょうか？ 私の担当サービスでもxUnitを使ってプロダクトコードにテストコードを作成して、CIツールのジョブで定期的にユニットテストを実行して品質維持に活用しています。 そして、それらテストコードがきちんと品質維持に貢献されていくためには、プロダクトコードのビジネスロジックをどれだけ網羅できているのか？　と言う観点が重要になってきます。 その観点の達成状況を確認する指標の1つとして、ユニットテストを実行した時に行われるコードカバレッジ解

ここまで見せます！高負荷ECサイト向けアプリケーションサービスの品質保証HowTo （tokyoLinuxStudy#005）

2015年2月24日　ヒカ☆ラボ発表資料 Webアプリケーション負荷試験実践入門 ■スライドの目的 負荷試験の重要性を認識して頂く 意味のある負荷試験を最短距離で行うための“段取り”を持ち帰って頂く 内容的には、主にAWS上のLAMP構成のシステムに対する負荷試験ですが、負荷試験ツールに依存しない全般的に通用する話を扱っています。Read less

前置き 前回のエントリーの続きになります。 JMeterのインストールや基本的な使い方は前回のエントリーを見てください。 JMeterを使ってRailsアプリの負荷テストをやりたい 準備編 http://qiita.com/t_cyrill/items/f2236b010a6b4ff04b9e authenticity_tokenを取り出す RailsのアプリはCSRFを防止するため、authenticity_tokenという名前のトークンを発行するため、Apache BenchなどのツールでPOSTのテストを行うのは難しいのですが、JMeterには正規表現にマッチする文字を一時変数のような形で保持できる機能があるので、少し設定するだけで負荷テストが行えるようになります。 前置きはこれくらいにして、早速authenticity_tokenを取り出して、RailsアプリがPOSTをうまく処理

書かないと怒られるし、書きたいとは思っているが、書くまでの敷居がやたらと高くなってしまった気がしている人へ。 最小のテスト 本質的にテストを書くのにフレームワークはいらない。 assertion だけあればいい。 isomorphic にしたいなら、 node の assert モジュールすら使わず console.assert だけで書ける。 // assert function assert(actual, expected) { console.log('.'); console.assert(actual === expected, '\nact: ' + actual + '\nexp: ' + expected); } function TestSum() { assert(1+2, 3); } // exec TestSum(); あとは普通にこのスクリプトを node/io

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

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフー株式会社の有地です。 9/27（土）の昼から6時間にもわたり、さまざまな視点から「レガシーコード」について知識を深めるための勉強会を開催いたしました。 「そもそも正しい仕様を知っている人がいない」 「システムのブラックボックス化が留まるところを知らない」 こんな不条理なレガシーコード（テストコードが無いコード）と日々戦うエンジニアも多いことと思います。 今あるレガシーコードをどうやって保守・改善していけばよいのかという課題に本気で取り組んでいる、または取り組みたいと考えている大勢の方々に参加していただきました。 ＜開催趣旨・目的＞ テストコードが無いプロダクションコードをレガシーコードと定義し、テストコードによって保護され、

最近の RSpec は、それまで obj.stub(hoge: value) と書けたものが、 allow(obj).to receive(:hoge).and_return value と書かないといけなくなったりとか、正気の沙汰とは思えないような変更をしたりするので、何年かぶりに Test::Unit を使ってみようとリハビリ中です。 RSpec は、テストケースを入れ子にできたり、テストケースや example がクラスやメソッドではなく、文字列で自由に書くことができたりしたのが良かったのですが、最近の Test::Unit ではそれもできるようになっています。 [ruby-list:48926] [ANN] test-unit 2.5.2 このリリースはとみたさんに使ってもらえるように改良したリリー スです。新しく追加した--locationはRSpecの--line_number

API MONITORING Trust Your APIs Less downtime. Fewer support tickets. Faster time to resolution. We’ll tell you when your APIs break before your customers do.

初登場の @tototoshi です。今回は pixiv のユニットテストで利用しているモックライブラリの紹介をします。 ここ2ヶ月くらいの間、レガシー化したとあるモジュールのリファクタリングに取り組んでいました。 リファクタリングにはテストコードが必須です。しかし今ではすっかりテストを書く文化が根付いている pixiv にもテストコードがない時代がありました。リファクタリングが必要な古いコードにはテストコードがないことが多く、そういったコードに新たにテストをつけていくのはなかなか大変です。テストの概念のないプロジェクトはテスト可能なように設計・実装されていません。テストを書くのが大変なのではなく、書けるようにするまでが大変です。 特にやっかいだったのは DB を参照したりするようなスタティックメソッドを使ったメソッドのテストでした。以下のようなスタティックな Dao を使用した Serv

今朝聞いた今週の rebuild.fm のポッドキャストで、テストに関する話題がとても面白く勉強になりましたので備忘録メモ。全部テスト書いてたら時間が足りないし、個人的にはどの部分を重点的にテストすべきか、削っても良いのはどこかに注目して聞きました。 Rebuild: 43: Kent is More Professional (Kenn Ejima) 以下 rebuild.fm 話題から参考にしたいメモ ・テスト書くのは良いが、テスト原理主義、100％カバー、全部テストファーストにこだわるのは疑問。 ・内部構造、実装に対するテストは書かない。 ・モックは一番外側のAPI、インターフェースに対してだけ使う。（※） ・モックのためのモックとかは避ける。 ・リファクタリングのためにテストを書き換えなきゃいけないようなテストは駄目。 ・テストとコードを同時に変更すると、トラブルに気付きにくくなる

DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco