こちらの記事は，Firebase.yebisu #1のLTに補足解説を加えたものになります． 発表スライド 当日お話できなかった，実施する際の注意などもありますので，ごさしゅーください． #tl;dr 高頻度のドキュメント作成（自動ID）で500/secに引っかからないことを確認できた 急激にアクセスが増えると503が出る場合がある（1秒で0→7万仮想ユーザなど） Loadroidはいいぞ #背景 ##動機 Firebaseの新しいデータベース，Firestoreは安価，安定，既存より柔軟で非常に魅力的です（詳細は過去記事参照）． しかし，ドキュメント内の制限事項に気になる表記がありました． ある条件1では，書き込み頻度に上限があるという内容です． Maximum write rate to a collection in which documents contain sequentia
前々から、Python, Django 界隈の単体テスト事情をまとめたいと思っていたのですが、こんな素敵なまとめ記事を見つけました。 Python用のユニットテストツールまとめ | TRIVIAL TECHNOLOGIES 4 @ats のイクメン日記 この記事では、unittest, unittest2, doctest, py.test, nose のほか、それこそ聞いたことのないようなものまで取り上げてくれているのですが、今回は、自分で使いそうな範囲のテストツールについて少しディープにまとめてみようと思います。 取り上げるのは、以下の 4種類（「Django + unittest」を unittest としてカウントすると 3種類）のテストツールです。 ほかにも、pytest や doctest も取り上げたかったのですが、まだ使ったことがなかったので割愛します（後で書くことになるか
この記事は、はてなエンジニアアドベントカレンダー2016の12月18日の記事です。 はてなエンジニアアドベントカレンダー2016を始めます - Hatena Developer Blog 昨日はid:ikesyoさんの「オープンソース活動への取り組み方」でした。 オープンソース活動への取り組み方 - Hatena Developer Blog こんにちは。はてなでWebオペレーションエンジニアとして働いているid:taketo957です。 2016年の4月に新卒として入社してからは、社内の仮想化基盤のリソース最適化に取り組んでみたり、 speakerdeck.com 社内の広告配信システムの刷新プロジェクトに関わってきました。 speakerdeck.com 本記事では広告配信システムの刷新を行う中で取り組んだ負荷試験環境を構築する際に考えたことと「継続的にパフォーマンス改善を行うためには
golangでIOへのテストを行う | おおたの物置 まとめ fmt.Print等にちゃんと出力されるかテストしたい 結論としては直接は無理 io.Writerを利用するように変えることで簡単にテスト可能 渡されたio.Writerに書き込むようにする ... http://ota42y.com/blog/2015/04/01/go-io-test/ golang には Example Test という機能があり、テスト関数名に Example のプレフィックスを付ける事で実行結果として出力される標準出力のテストを行う事が出来ます。 期待する結果はこの関数の中にコメントとして書くことが出来ます。 go-pipeline/example_test.go at master - mattn/go-pipeline-· GitHub https://github.com/mattn/go-pip
PythonやJavaでコードを書く場合、コードカバレッジの測定は、よくやりますよね。最近、Ansibleでもコードカバレッジを測りたくなったのですが、それらしいツールがなかったので、作ってみました。名前はKirbyです。今回はKirbyがどんなツールなのか紹介してみます。 ks888/kirby · GitHub どんなことができるのか Kirbyは、AnsibleのPlaybookやRoleに対して、タスクレベルのカバレッジを測定するツールです。 例えば、次のようなPlaybookと、Serverspecのテストがあったとします。Playbookでは2つのタスクを実行しています。Serverspecのテストでは、Playbookの一つ目のタスク（create dir1）に対するテストをしています。 ~/src/kirby_demo% cat create_2dirs.yml --- -
« lingr で stackverflow を検索出来る bot を golang で書いた。 | Main | Vim scriptで「ソフトウェアエンジニアならば1時間以内に解けなければいけない5つの問題」を解いてみた » willnet/gimei - GitHub gimei は、日本人の名前や、日本の住所をランダムに返すライブラリです。テストの時などに使います。似たようなライブラリにfakerがあります。fakerはとても優れたライブラリで、多言語対応もしていますが、ふりがな(フリガナ)は流石に対応していません。gimei ふりがな(及びフリガナ)に対応しています。 https://github.com/willnet/gimei オリジナルは ruby gems です。 mattn/go-gimei - GitHub golang port of gimei https://
highly extensible, highly enjoyable, BDD testing framework for PHP. Natural Testing with Peridot is natural. Write tests using the familiar describe-it syntax. Easily and clearly describe how your code should behave in a language that makes sense. See getting started. Extensible Peridot is event driven, so writing plugins or ad hoc extensions is painless. Peridot events and scopes allow you to eas
Google Play In-App Billing テスト方法
続きの続き。Google PlayのIAB(In-App Billing)のテストの話を乗せときます。 あまり載せることがないので、基本的には オフィシャル の内容ほぼそのままです。 Google Playのアプリ内課金テストではAmazonのIAPのようなテストアプリは使いません。同様の機能をPlayStoreが既に備えています。また、本番環境でのテストをする方法も既に用意されています。 ２つのテスト方法 Google Play には、アプリ内課金の実装テストに役立つ２つの機能が用意されています。 サンドボックステスト 予めテスト用に予約されたアイテムIDを使って、所定のレスポンス時のテストを行える。 実購入テスト Google Playを通じて実際の購入と同じ環境でアプリ内課金を行うことができる。こちらはGoogle Playへの通信を行い、実際にGoogle Walletへの取引が発
これは人それぞれのコードの書き方に依存するので必ずしも筋悪というわけではない。むしろそういう風に書いてしまえる人もいるだろう、くらいの話。 何が言いたいかというと、自分の場合、ある程度は頭の中でまとめつつとりあえず手を動かして書いてみる→気に入らなかったり、後から「これではあかん」と思ったらインタフェース変える、みたいなことを繰り返しながら、要は同時にリファクタリングしながらコードを書いていくので、初めから厳密すぎるテストを書いてしまうと手戻りが多くなって非効率的なのである。 例えば、とあるJavaScriptのメソッドの返り値がこんな感じだったとしねえ。 { valid: true, foo: 10, bar: 0 } で、"valid"の部分はほぼ間違いなくこれで行くけど、"foo"と"bar"の部分は後から無くすかもしれない。あるいはkey名を変えるかもしれない。あるいは何か別のke
テスト書きすぎ問題 - hitode909の日記 階層が増えるとテストが増える - はこべブログ ♨ テストと対応関係 - $shibayu36->blog; 最近書いているWebアプリは、HTTPリクエストを送ってレスポンスと状態をテストする、というテストだけ書くようにしてる。リクエストするとブログエントリを返す、というサービスだとこういう風なテストを書いてる。(HTMLを返すようにすると話が広がって説明が面倒なのでJSONを返すAPIで説明する) describe "Entry resource" do let(:params) do {} end let(:env) do { "HTTP_AUTHORIZATION" => "Bearer: #{access_token.token}" } end let(:access_token) do AccessToken.make(user
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
開発部の栗田です。End-to-Endテストの効率化をテーマにプレゼンを行いましたので概要を紹介させて頂きます。 繰り返しのテストを自動化してくれるSelenium WebDriver。（以下WebDriverと呼びます） 過去長い時間マニュアルテストをしていた私には、夢の様なツールで大好きです。 スモークテストを自動化して、随分助けて頂きました。 しかし確認作業を全部自動化出来るかというと、実はそうでは無いようです。値の検証は得意で動作テストは概ね自動化できそうですが、「見た目の不具合（レイアウトバグ）」を見つけるのは苦手だと思います。 レイアウト確認をマニュアルで行おうとすると、確認に至るまでの操作もマニュアルで行う事になります。そうなると、動作確認を自動化するするメリットが減ってしまいそうです。 そんな苦手分野を克服する方法の紹介です。 <目的は時間の削減、自動化は方法、半自動でも時
Cram is a functional testing framework for command line applications based on Mercurial's unified test format. Cram tests look like snippets of interactive shell sessions. Cram runs each command and compares the command output in the test with the command's actual output. Here's a snippet from Cram's own test suite: The $PYTHON environment variable should be set when running this test from Python.
cramという便利なものがあります。これは語弊のある言い方をするとRubyでいうcucumber/turnipのようなテストツールです。サンプルを見たほうが早いと思いますが、普通にMarkdownとかを書く感じでテストを書けて、コマンドの想定される出力と実際のものを比較してtrue/falseを判定するみたいなやつです。想定と実際の出力とのdiffがなければグリーン、期待と違えばレッドです。 Vagrantのテストというとserverspecが勢いありますが、cramはもっと生っぽいテストをかけます。serverspecではshould be_enabledのように、書くのは簡単だけど実際に何をテストしているのかはソースコードを見ないとわからないので、テストがこけた場合の原因調査がちょっと厄介です（例えばRedhat系ならchkconfigの結果を見ています）。とはいえcramでパッケージ
Read it now on the O’Reilly learning platform with a 10-day free trial. O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers. Book description The advent of modern programming frameworks such as Rails and Django, together with the ready availability of virtualisation, and the explosion of interest in configur
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
