私は次のようにMSTestプロジェクト内でNUnitアサーションを使用しています（注：これはDave Falknerの回答へのコメントを参照してください）：
using Microsoft.VisualStudio.TestTools.UnitTesting;
using MSTestExtensions;
using Assert = NUnit.Framework.Assert;
using Is = NUnit.Framework.Is;
これは単体テストではうまく機能しましたが、統合テストでは問題が発生しています。私の単体テストではMSTestExtensionsを使用していなかったため、MSTestExtensionsが原因である可能性があります。さらに、MSTestExtensions usingステートメント、クラスの継承MSTestExtensionsTestFixtureステートメント、および属性をコメントアウトすると、[TestTransaction]この問題は発生しません。usingステートメントを追加し直しても、問題は発生しません。[TestTransaction]属性を追加しても、問題は発生しません。テストクラスのMSTestExtensionsTestFixtureから継承すると、問題が発生します。
基本的に、問題は、失敗する状況で次のコードを実行すると（たとえば、actualPartNumbersリストに2つの部分が含まれているのに対し、期待されるリストには1つしか含まれていない）、AssertionExceptionがMSTestによって処理されないことです。
Assert.That(actualPartNumbers, Is.EquivalentTo(expectedPartNumbers));
したがって、IDEはテストに失敗するのではなく、スローされた例外で停止します。これが起こらず、テストが正常に失敗する場合があります。ただし、ほとんどの場合、IDEはスローされた例外で停止します。何か案は？
参考：[TestTransaction]各テストの後にデータベースのロールバック（属性）を
実行できるように、MSTestExtensionsを使用しています。これは、MbUnitのロールバック機能に似ています。流暢なスタイルの方が好きなので、MSTestのアサートをNUnitのアサートでオーバーライドしています。最後に、NUnitに問題があるため、MSTestを使用しています。特にMicrosoftMolesと競合し、log4netを使用するサードパーティの参照と競合します。切り替えた場合にどちらのフレームワークでも実行できるように、ユニット/統合テストをセットアップするために最善を尽くしています。しかし今のところ、MSTestは最も面倒ではないようで、IDEへの統合は非常に優れています。