利用可能なすべての回答を試しましたが、ピット ミューテーション テストの実行中にこのエラーが発生します。同じ構成の他のシステムでも問題なく動作します。このエラーに関するヘルプをいただければ幸いです。ありがとう。

コンソールログ

ミューテーション テストを少しいじっているだけですが、理解できないことが 1 つあります。次のような for-each ループに常に「否定された条件付きミューテーター」を適用しようとするのはなぜですか。

mutator の説明 ( http://pitest.org/quickstart/mutators/#NEGATE_CONDITIONALS!= ) を見ると、 to==や<toなどの条件を変更する必要があり>=ます。そのため、なぜそこで使用されているのか、なぜ失敗するのか、しないのかがよくわかりません。

誰か説明してくれませんか？

私は c# で新しいプロジェクトを開始しており、突然変異テストを行うのに役立つツールを探しています。以前に、 pitestを使用して Java で突然変異テストを行ったことがあり、とても気に入りました。現在、私はC＃用のそのようなツールを探していますが、見つけることができる唯一のものは、過去数年間更新されていないか、まだアルファ/ベータ（クリーム、ニンジャタートル、ネスター）です。

信頼性が高く、2010 年以降に登場したツールで使用できるツールはありますか?

編集: この質問はWhat Mutation-Testing Frameworks exist?の複製であると言う人もいるかもしれません。【閉店】 . その質問だけが現在 8 年前のものであり、そこで議論されているツールのほとんどは、過去 6 ～ 8 年間更新されていないため、使用できません。

この質問が非常に漠然としていることは承知していますが、あなたの助けがあれば改善できると思います。数か月前、TDD と単体テストについて話しているインタビューで、いくつかの行を削除または変更することによって (自動的に、おそらく特定のツールを使用しています）。ご想像のとおり、私は仕事に就けず、彼らに直接質問することはできませんが、興味深いトピックのようで、彼らもそれを使用しているようです. 誰かがそれについて聞いたことがありますか？

私は 1 点で立ち往生しており、提案が必要です。

私のコードのjunitを書いている間、 ValidateArgument.notNull(arg1) 突然変異を殺すことができません!!!
提案が必要です。

コードは次のようになります。

取得

## com/nokia/oss/configurator/rac/common/util/ValidateArgument::notNull への呼び出しを削除 → SURVIVED

戻り値の型はvoid、この突然変異を殺す可能性のある方法は何ですか?

Guava の PIT ( http://pitest.org/ ) を設定してミューテーション アデカシー テストを実行しようとしていますが、実行しようとすると次のエラーが発生します。これは私が得るエラーです:

基本的に、PIT がテストを検出していないか、PIT でテストが正しく実行されておらず、すべてのテストが失敗しています。私はこの投稿を読みました：JUnitテストはパスしましたが、PITはスイートがグリーンではないと言い、「コードベースには変更可能な静的状態が含まれていますか？（シングルトンなど）」が問題だと思いますが、修正方法がわかりません。テスト スイートに隠れた順序の依存関係がある場合、PIT を実行できるようにするにはどうすればよいですか? それとも、テスト スイートは単に PIT と互換性がないのでしょうか?

Rails プロジェクトにミューテーション テストを追加しようとしています。

バンドラーで正しくインストールされているように見えるGemfileで

しかし、ミュータントで何かをしようとした後、ミュータントを開始しようとすると、常にこのエラーが発生します。

私のインストールには何かが欠けていると思いますが、わかりません。何が欠けているのでしょうか?

openHFT/java-runtime-compilerを使用して、ディスク アクセスの多用からインメモリ コンパイルのみの使用まで、ミューテーション テスト ツールを改善しようとしています。

変異テストでは、2 種類のクラスがありました 。 A. 変異クラス、その定義が常に操作/変更され、再コンパイルされるクラス。 B. その他のクラス、その定義が変更されないクラス、つまりテスト ケース クラス、または変更されたクラスが必要とするその他のクラス。

openHFT/java-runtime-compiler を使用すると、以下のコードを使用して簡単に実行できます。これは、変更されたクラスと他のクラスの両方を再コンパイルするたびに新しい classLoader を作成することでした。

これはうまく機能し、クラス A の新しい定義がコンパイルされるたびに、AClassは新しい定義に適応します。

ただし、以下のコード ( BClassが最初にロードされ、次にAClass ) のように順序が逆になっていると、これは機能しません。クラス A の再コンパイルは、新しい定義に適応せず、クラス A のコンパイルに使用された最初の定義を常に使用します。

openHFT/java-runtime-compiler ライブラリ (以下のコード) からloadFromJavaクラスを変更する必要があったのではないかと思います。私はすでに行を省略して試しています

loadFromJavaが呼び出されるたびに、すべてのソースコード (既にコンパイルされているものも含む) を常に再コンパイルするようにすることを期待していました。しかし、それは間違った結果をもたらします。

機能させるために必要な変更を指摘するのを手伝ってください。

大変お世話になりました。

編集済み

ピーター・ローリーに感謝します。あなたの提案を試してみましたが、同じ結果が得られました。A クラスは最初に使用された定義に固執し (最初の反復で)、新しい定義への変更/使用に失敗しました (次の反復で)。 .

私は症状を集めました。考えられる説明は、次の反復とは異なる最初の反復 (初めてクラスがコンパイル/ロードされた) の処理があったことです。そこから、いくつかのことを試します。

第 1 の症状

loadFromJava (下) に出力行 (System.out.println) を入れたときでした。

出力は次のとおりです。

最初の反復では、loadClassesMap には classLoader がないため、正しい出力 "loadClasses Null" (B をロードするとき) が返され、loadClassesMap には classLoader があるが、ないため、"clazz Null" (A をロードするとき) が返されました。 t は A クラス名を持っています。

ただし、次の反復では (A をロードするとき)、「clazz Not Null」が出力されます。A クラス名が既に loadedClassesMap.get(classLoader) に格納されているように見えますが、これは発生しないはずです。CachedCompiler コンストラクターで loadedClassesMap をクリアしようとしました。

しかし、それは LinkageError: loader (main/Utama$2 のインスタンス): 重複したクラス定義を試みました。

2 番目の症状

最初の繰り返しでの差別化のより強い症状は、s_fileManager バッファーをチェックしたときでした。

最初のイテレーションは予想どおりでしたが、次のイテレーションでは、s_fileManager バッファーは既にサイズ 2 を取得しているようで、0 にリセットされていません。

CachedCompiler コンストラクター (以下) で FileManager バッファーをクリアしようとしましたが、

しかし、ExceptionInInitializerError が発生します。