次世代のモックフレームワークであるJMockitの基本的な使い方 - 達人プログラマーを目指して
以前のモックフレームワークの技術的制約 今まで私が担当してきたプロジェクトにおいては、モックオブジェクトを使ったJUnitの単体試験はjMockとEasyMockのいずれかのフレームワークを利用して行ってきました。しかし、これらのフレームワークはJavaプラットフォームにおけるコード自動生成の考え方の変遷で説明したように動的プロキシーに基づいているため、以下のような制約がありました。 モック化する対象の型はインターフェースを実装しているか、継承可能なクラスであること モック化するメソッドはfinal、static、privateでないこと*1 モック化するロジックはコンストラクターの呼び出しではないこと モックオブジェクトをテスト対象クラスにDIかパラメーター経由で引き渡すことが可能であること モック化する場合はクラス全体をモック化する必要があること（getterやsetterなどは本物の
ビジネスロジックのテスト自動化
●１ 障害件数が減らないのはなぜか？ テストには、単体テスト(UT)、結合テスト(IT)、システムテスト（ST）、ユーザ受入れテスト（UAT）などの工程がありますが、 私の経験からいうと最も障害が発生する確率が高いテストは結合テストだと思います。 なぜ、そんな事になるのかというと以下のような理由からです。 ①単体テスト工程が、関数レベルのテストとなり、ビジネスロジックとしてのテストがされない。 ②単体テスト工程で完全なテスト項目を作り上げ、完全なテストを実施する事はまれである。 では、どうすれば結合テストにおける障害件数を抑制する事が出来るのでしょうか？ 結合テスト以降の障害件数を少なくするには、以下のようにテストを実施すれば良いのです。 ①ビジネスロジックレベルのテストを単体テスト工程で実施する。 ②ブラックボックスレベルで完全なテスト項目によるテストを実施する。 しかし、実際には、結合
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
