Javaでユニットテストを書く時に気を付けたいこと - 覚えたら書く
Javaプログラムに対するユニットテスト(単体テスト)を書く際に気にしておきたいことを書いてみました。 以下、個人的な経験則と本で読んだ内容が混ざっています ユニットテスト作成時の原則 「このクラスはＸＸＸの理由でユニットテストが難しいんです！」と言いたくなったら ⇒ ユニットテストし易いように対象のクラスを作る（作り直す） 一般的にこのような設計の変更をした方が実運用にも適していたり、要件変更への対応が柔軟になったりする場合が多いです privateメソッドを強引にユニットテストしない リフレクションを使って出来なくはないが、基本的にやるべきではない。ユニットテストが内部の実装に依存しすぎる 呼び出し元のpublicメソッドのユニットテスト経由で処理を網羅すればよい どうしてもprivateメソッドのテストをしたいなら、そもそもprivateメソッドではなく別クラスのpublicメソッド
Mockitoノススメ - Fly me to the Luna
モックライブラリ使ってますか? 僕はJavaの人なので、主にJUnitを使ってテストコードを書いています。テストコードを書いている最中、「もしこのオブジェクトから例外が帰ってきたら、ちゃんと例外のハンドリングができてんの？」等々、既存のオブジェクトの振る舞いを差し替えたくなることってありませんか？そういうときにモックライブラリを使うと、既存のオブジェクト処理を差し替える事ができます。 実は最初はモックライブラリって意味あるの?と懐疑的だったんです。どういうところに懐疑的だったかというと、 テストコード中に出てくるモックライブラリのセットアップがめんどい。 テストコードがプロダクトコードの実装に依存しちゃうんじゃないの？プロダクトコードをちょっと変えただけでテストが落ちるようになるんじゃないの？ みたいなところです。でもMockitoというモックライブラリを使ってテストコードを書き初めてから
Mockitoの記述方法 - Qiita
JUnit + Mockitoでテストする際のMockitoの記述方法が紹介するページによりマチマチなので自分なりに整理した。 環境 Mockito v2.23.9 JUnit v4.12(JUnit5にしたい) Mockitoの機能 Mock 対象インスタンスのメソッドをすべてモック化して置き換えたい場合に使用する。 デフォルト状態では、オブジェクトの場合、戻り値があるメソッドはnullを返すようになる。(Collectionでは空のCollectionだったり、プリミティブな値では0とかfalseとか...) @Mockのアノテーションを付与することでモック化できる。 また、テスト対象となるクラスのインスタンスに@InjectMocksを付与することで、 インスタンス内の@Injectされたメンバーのインスタンスに@Mockのモックインスタンスを差し込むことができる。 Spy 対象のイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Writing Parameterized Tests With JUnit 4
How do I assert equality on two classes without an equals method?
http://www.unitils.org/tutorial-reflectionassert.html
How to verify Map size using Hamcrest
Map equality using Hamcrest
へたれエンジニアがJaCoCoを使ってカバレッジレポートをとってみた(gradle×JaCoCo）｜まるブロ -へたれエンジニアが頑張ります-
Testing Multiple Properties With a Single Assertion - DZone
Hamcrest - How to assertThat check null value? - Mkyong.com
3 basic mistakes for NullPointerException when Mock | CodePills.com
Mockito: Trying to spy on method is calling the original method