2025
01
18
2008
09
11
Assert クラスの使用
UnitTestingFramework 名前空間の Assert クラスは、個別の機能を確認するために使用します。単体テストのメソッドでは、開発コード内のメソッドのコードを実行しますが、Assert ステートメントを含めたときにのみコードの動作に関するレポートが出力されます。
メモ : |
---|
Assert ステートメントの有無に関係なく、単体テストではコード カバレッジ データを生成できます。詳細については、「方法 : コード カバレッジ データを取得する」を参照してください。 |
Assert の種類
Microsoft.VisualStudio.TestTools.UnitTesting 名前空間には複数の Assert クラスが用意されています。
テスト メソッドでは、Assert.AreEqual() などの Assert クラスのメソッドを任意の数だけ呼び出すことができます。Assert クラスには、多くの選択可能なメソッドがあり、それらのメソッドの多くには複数のオーバーロードが存在します。
CollectionAssert クラスを使用して、オブジェクトのコレクションを比較したり、1 つ以上のコレクションの状態を確認したりします。
StringAssert クラスを使用して、文字列を比較します。このクラスには、StringAssert.Contains、StringAssert.Matches、 StringAssert.StartsWith など、さまざまな便利なメソッドが含まれています。
AssertFailedException 例外は、テストが失敗すると常にスローされます。タイムアウトした場合、予期しない例外がスローされた場合、または "失敗しました" の結果を出力する Assert ステートメントを含む場合、テストは失敗します。
AssertInconclusiveException は、テストで "結果を作成できません" の結果が出力されると常にスローされます。通常 Assert.Inconclusive ステートメントは、まだ編集中のテストに対して、そのテストを実行する準備ができていないことを示すために追加します。
メモ : |
---|
他の方法としては、実行の準備が整っていないテストに Ignore 属性を設定して示す方法もあります。ただし、この方法には、まだ実装していないテストの個数に関するレポートを簡単に作成できないという短所があります。 |
新 規の Assert 例外クラスを作成する場合には、そのクラスに UnitTestAssertException 基本クラスを継承させると、例外が発生した場合に、その例外がテストや製品コードからスローされた予期しない例外なのか、アサーションによる失敗なのかを 識別しやすくなります。
ExpectedExceptionAttribute 属性をテスト メソッドで使用して、開発コード内のメソッドによって例外がスローされることが予期される場合に、例外が実際にそのメソッドでスローされたかを確認します。
Assert.AreEqual による安全でないオーバーロード型
Assert.AreEqual メソッドには、多くのオーバーロードが存在し、個々のデータ型を比較できます。ただし、Assert.AreEqual メソッドには、ポインタ データ型など、安全でない型に対するオーバーロードは存在しません。
これを示すために、次のクラスを含む C# コンソール アプリケーションを作成します。
unsafe public class CUnsafeTest
{
private int* m_pX = null;
unsafe public void VoidPtr(void* voidPtr)
{
}
unsafe public int* ReturnPointer(float* fPtr, TestThis* pTestThis)
{
int x = 5;
return &x;
}
}
次に CunsafeTest クラス用のテストを生成します。詳細については、「方法 : 単体テストを生成する」を参照してください。次の例と同様のコードが生成されます。
[TestMethod()]
public void ReturnPointerTest()
{
unsafe
{
CodeGen.BVT.Unsafe.CUnsafeTest target;
target = new CodeGen.BVT.Unsafe.CUnsafeTest();
// TODO: Initialize to an appropriate value
System.Single* fPtr = null;
// TODO: Initialize to an appropriate value
TestThis* pTestThis = null;
// TODO: Initialize to an appropriate value
System.Int32* expected = null;
System.Int32* actual;
actual = target.ReturnPointer(fPtr, pTestThis);
Assert.AreEqual(actual, expected);
// On the preceding line, no overload is available.
}
}
この場合には、Assert.AreEqual ステートメントを、独自のカスタムな検査コードに置換する必要があります。
2008/09/11 (Thu.) Trackback() Comment(0) C++
2008
09
11
テスト プロジェクトと Visual C++
テスト プロジェクトと Visual C++
テスト プロジェクトには、プロジェクトに設定したコンパイラ オプションに基づいて、さまざまな機能があります。詳細については、「コンパイラ オプション」および「/clr (共通言語ランタイムのコンパイル)」を参照してください。次のセクションでは、さまざまなコンパイラ オプション設定で利用できる機能について説明します。
アンマネージ
テスト プロジェクトのプログラミング言語として、アンマネージ (ネイティブ) Visual C++ は使用できません。
混合
混合プロジェクトとは、/clr コンパイラ オプションを使用するプロジェクトです。この種類のテスト プロジェクトでは、次の実行コードをテストする機能が提供されています。
-
静的なネイティブ ライブラリ
-
ネイティブ DLL エントリ ポイント
-
スタンドアロン .obj ファイル
-
呼び出し可能なメソッドを備えた混合モード DLL アセンブリ。実行可能ファイルにはアンマネージ コードが含まれ、一般にアンマネージ実行可能コードは、再ベース アドレス対応ではないため、これには実行可能ファイルは含まれません。
-
呼び出し可能な任意のマネージ メソッド。/clr:pure または /clr:safe のコンパイラ オプションでコンパイルされるコードです。
安全または純粋
/clr:pure または the /clr:safe のコンパイラ オプションをテスト プロジェクトで使用している場合は、呼び出し可能なマネージ メソッドをテストできます。つまり、/clr、/clr:pure、または /clr:safe のコンパイラ オプションでコンパイルされる実行コードです。
コードの生成と Visual C++
単体テストを Visual C++ テスト プロジェクトに生成できます。これらのテストは Visual C++ 実行コード プロジェクトから生成できます。次の点に注意してください。
-
実行コード プロジェクト。実行コードが Visual C++ で記述されている場合、製品で /clr:safe コンパイラ オプションを使用する場合のみ単体テストを生成できます。
-
テスト プロジェクト。 コードの生成によって、Visual C++ テスト プロジェクトのあらゆる種類 (混合、安全、および純粋) で単体テストを作成できます。作成される既定のプロジェクトの種類は、/clr:safe プロジェクトです。プロジェクトを /clr または /clr:pure に変更する場合、常に Visual C++ コンパイラ オプションを使用して、それを行います。詳細については、「/clr (共通言語ランタイムのコンパイル)」を参照してください。
2008/09/11 (Thu.) Trackback() Comment(0) 未選択
2008
09
11
VS2005の単体テストについて
<よく使うもの>
メソッド名 | 効用 | どんなときに「失敗」を返却するか |
---|---|---|
Microsoft.VisualStudio.TestTools.UnitTesting | ||
AreEqual(a,b,message) | 単純比較する | aとbが等しくないとき、メッセージとともに「失敗」を返却します。 |
AreNotEqual(a,b,message) | (AreEqualの逆) | |
AreSame(a,b,message) | (AreEqualのオブジェクト参照版) | aとbのオブジェクト参照が等しくないとき、メッセージとともに「失敗」を返却します。 |
AreNotSame(a,b,message) | (AreNotEqualのオブジェクト参照版) | |
Fail(message) | 無条件に失敗させる | メッセージとともに「失敗」を返却します。 |
IsNull(a,message) | 参照がNull(Nothing)参照であるか検査する | aがNull(Nothing)であるとき、メッセージとともに「失敗」を返却します。 |
IsNotNull(a,message) | (IsNullの逆) | |
IsTrue(a,message) | Boolean判断をする | aがFalseであるとき、メッセージとともに「失敗」を返却します。 |
IsFalse(a,message) | (IsTrueの逆) | aがTrueであるとき、メッセージとともに「失敗」を返却します。 |
IsInstanceOfType(a,type,message) | 型を検査する | aがtypeで定められた型でないとき、メッセージとともに「失敗」を返却します。 |
IsNotInstanceOfType(a,type,message) | (IsInstanceOfTypeの逆) |
2008/09/11 (Thu.) Trackback() Comment(0) 未選択
2008
09
11
LOG4CXX_DEBUG
* 6. The LOG4CXX_DEBUG and similar use the LOG4CXX_LOCATION
* macro to define the log statement location instead of
* using __FILE__ and __LINE__. Logger::debug and
* similar now take const LocationInfo& instead of
* separate const char* and int arguments. This allows
* class and method names to appear in location info.
2008/09/11 (Thu.) Trackback() Comment(0) 未選択
2008
09
11
logcxxについて
継承に注意:
↓の場合log4j.logger.ASD.ZXC=WARN, A2
logger.ASD.ZXCは、logger.ASDを継承しているので、log4j.logger.ASD.ZXCを使っても、出力は
Appender A1 と A2
の両方を使って行われる。つまり、二重に出力される。
で、継承を受け継がなくさせるには、additivity を使う。
Logger.additivity:
additivityを false に設定すれば、それまでの親の設定は受け継がない。additivityの設定は
Appenderのプロパティ設定は
log4j.appender.ASD.ZXC.layout=~
なのに!何故!!
%Mは無い。
%Cも無い。
%c Logger名を出力。 cは、Categoryの名残か
%C クラス名を出力。無い
%d 日時 %d{HH:mm:ss} や %d{dd MMM yyyy HH}など
%F ファイル名
%l ファイル名と行番号
%L 行番号
%m ログメッセージ
%M メソッド名 無い
%n 改行文字
%p 優先度(Level)。 Priorityの名残か
%r アプリケーションが開始してから、ログが出力されるまでの時間をミリ秒単位で出力。
%t プロセスID
%x スレッドのNDC(ネスト化診断コンテキスト) を出力。
%% %を出力する。
2008/09/11 (Thu.) Trackback() Comment(0) 未選択