JavaScriptのベンチマークテスト機能を簡単に組み込める「JSLitmus」:phpspot開発日誌
JSLitmus JSLitmus is a lightweight tool for creating ad-hoc JavaScript benchmark tests.JavaScriptのベンチマークテスト機能を簡単に組み込める「JSLitmus」 ページ内のJavaScriptのパフォーマンスを、ページ内に表示される次のようなウィジェット内でテストできます。 Google Chart API を使ったパフォーマンスのグラフの出力も出来るみたい。 scriptとしては次のように書いてテストウィジェットを表示するようです。 <script src="JSLitmus.js"></script> <script> JSLitmus.test('Empty function test', function() { /* ここに計測したい処理を記述 */ }); </script> ↓↓↓
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
テストケースの「正常系/異常系」というカテゴライズについて - ソフトウェアテストの勉強室
ソフトウェアテストには7つの原則(*)があって、そのひとつに「テストは欠陥があることしか示せない」という原則がある。これはどういうことかというと、テストというプロセスでは「不具合がない」ことは示せない、示せるのは「不具合がある」ことだけだ、ということを意味している。つまり、テストの目的＝不具合を見つけ出すことなので、より多くの不具合を見つけられるテストケースが優秀といえる。 テスト仕様書に「正常系/異常系」のカテゴライズは必要？ by クライングドーベルマン 第三者テスト、とかソフトウェアテスト専門部隊、に属する僕個人の意見としては、「正常系/異常系」のカテゴリーはテスト仕様書には特に必要ないように感じる。多分、「正常系/異常系」というカテゴリーはテスト実行の優先度として使用する目的で設定していると思うが、「とりあえず正常系から先にテストする」という戦略は時として重大なテスト漏れを発生させ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
