設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog;
以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;という記事を書いた。まだよい方法はちゃんと考えられてないが、少しずつケースバイケースでいろいろな手法を試してみている。今回は設定項目の仕様のドキュメントという観点で考えたときに、テストを作ることで解決できないか、ということについて書く。 設定項目の仕様 例えば以下の様な設定があったとする*1。 [ { "blog_url" : "http://shibayu36.hatenablog.com/", "permission" : "public", "can_be_edited_by" : [ "shiba_yu36" ] }, { "blog_url" : "http://shibayu36-private.hatenablog.com/", "permission" : "private", "can_be_
ウノウラボ Unoh Labs: テスト用ダミーデータ心得
こんにちは！ やまもと＠テスト番長です。 テストを行うとき、チェック用にダミーの入力をしますよね？ ダミーのデータを何にするか毎回考えるのは時間の無駄ですから 大体の場合、決り文句を用意しておくわけです。 例えばマイクロフォンのテストなら、「あー、テストテスト。本日は晴天なり。」なんて言いますよね。 今日はWEBアプリテスト用ダミーデータの作り方心得をご紹介しましょう。 専門書などでこういったトピックを探すと、有効なテストパターンの話になりますが 現場の知恵という側面から攻めてみます。 １）「テスト」と名乗ってはならない。 稼動中のWEBアプリの修正や追加機能をテストをする場合、本番環境と同等の開発環境が用意されているでしょう。そしてその両方でテストを行うことになります。 この時よくあるミスが、開発環境のつもりで本番環境をテストしてしまうこと。WEBアプリは一律ブラウザで閲覧さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
受け入れテスト用セキュリティチェックリスト for Webアプリケーション
