ふつうのユニットテストのための７つのルール - ブログなんだよもん
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記： テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記： もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
Perl Hackers Hub：第9回 高速なWeb APIの実装とテスト―Mobage APIを支えるノウハウ（2）｜gihyo.jp … 技術評論社
大量にあるサーバへのアクセスを効率的に扱う Mobage APIでは、接続するDBサーバやmemcachedサーバなどが大量にあります。サーバが増えても、アプリケーションの変更は最低限にしたいものです。ここでは、複数のサーバへのアクセスを簡単に記述する方法を紹介します。 DBへのアクセスを隠蔽する DBは一般的な、マスタ／スレーブ構成を採用しています。INSERT/UPDATE/DELETEのような更新系のクエリはマスタへ、SELECTなどの参照系のクエリはスレーブへいくようにしています。また、Sharding[11]をしているDBの系統もあります。 このように大量にあるDBへのアクセスを簡単に行うために、Mobage APIではDeNAの有澤高介さんが開発したDBIx::DBHResolver（現在のメンテナは同じくDeNAの山口徹さん）を利用してDBへのアクセス情報を隠蔽（いんぺい）し
Test::mysqldとDBIx::Skinnyを用いたテスト入門 - メメメモモ
MySQLを使ったアプリをテストするために「Test::mysqld」に入門してみました。 下記のスクリプトの主な流れは、 Test::mysqlでテスト用DBを作成 Test::Fixture::DBIxSkinnyでテスト用データを挿入 テスト用DBを用いてテスト という感じになっています。 また、 http://d.hatena.ne.jp/memememomo/20101109/1289304130 で用意したスキーマを用いています。 texture.yamlの内容。 参照(予定)リンク 知識が足りないために、参照リンクの内容をいまいち理解できていません。 テストをゴリゴリ書いていく上で参考にしていきたいと思います。 Kazuho@Cybozu Labs: Perl のテスト用に MySQL 環境を自動で構築するモジュール Test::mysqld を書いた DBIを使った例 Mo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bristlecone
