はじめに PITを使用してKotlinなAndroidプロジェクトでMutation Testingを導入するまでのメモです。 Mutation Testing テストコードが正しいかを計測するために、Mutant Testingという手法があります。 Mutant Testingではプロダクトコードを機械的に変更し、変更されたコードに対してテストを実行します。そしてテストが失敗するかを確認することで、プロダクトコードの振る舞いの変更をテストコードが検知できるかをチェックする手法です。 ミューテーション解析 - Wikipedia PIT 今回はMutation TestingツールとしてPITを紹介します。PITはJavaとその他JVM言語用のMutation Testingツールです。検索するときはpitestで検索すると良いです。 PITの素晴らしい点は、3rdパーティー製Andro
はじめに Gradle の設定 テストの実行 アサーション Matcher ライフサイクル Display Names @Tag Nested Tests コンストラクタとテストメソッドへの DI Assumptions Dynamic Tests ライフサイクルコールバック はじめに JUnit5 のリリースが近づいています。現在は M2 で M3 の作業が進んでいます。 今のところの予定は以下のようになってます。 2016/10/21 M3 リリース 2016/11/30 M4 リリース 2016/12/30 M5 リリース JUnit4 とは(中身は)全く別ものです。が普通に使う分には特に今までと同じ感覚で使えます。 Java8 以降をサポートという潔い割り切りになってます。 Version 5.0.0-M2 のユーザガイドからかいつまんでみます。 Gradle の設定 プラグインが
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか?」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
昨日のエントリーの続きです。 mike-neck.hatenadiary.com Gradle万能派の僕には、納得がいかなかったので、最後までやってみることにしました。 切り捨てたこと まず、分散テストは何が目的なのか考えると、テスト結果をマージすることが目的なので、以下のことは切り捨てました。 dockerの外でコンパイルしたクラスファイルの共有(昨日のドハマリその2により、共有してもコンパイルしてしまうので諦めた) srcディレクトリーの共有(Javaファイルを生成するタスクがある場合はsrcディレクトリーの共有をすると、各コンテナがJavaファイル生成を行ってしまうので、諦めた) 【2015/10/20 12:19追記】 つまり、コンパイル結果を共有しても再コンパイルされるので、buildディレクトリーの共有は諦めました この結果、妥協するのは次の点です。 各コンテナでソースコード生
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く