Exception später feststellen

Hallo,

Ich wollte wissen ob es später möglich ist, fest zu stellen ob eine Exception gab.

[TestMethod]
   public void DoMyTest1()
   {
       this.TMap.DoSomething();
       this.TMap.DoSomething2();
       this.TMap.AssertSomething();
   }

Es wird zB. diese TestMethode aufgerufen, und anschließend eine andere.
In der folgenden Methode will ich dann feststellen ob es eine Exception gab.
Falls es eine Gab soll en ein paar funktionen ausgeführt werden und die Exception "bereinigt/seitigt" werden, dasss wenn ich nochmal auf eine Exception prüfe nicht die alte erkannt wird, sondern eben ob es eine neue gibt.

Wie kann ich das feststellen? Oder ist das nicht möglich.

EXDW

Pro UnitTest sollte immer nur eine Sache getestet werden. Dadurch ist es auch an dem namen erkennbar.
Dh wenn du 2 mögliche Exceptions testen willst, brauchst du auch 2 Test Methoden.

1. Pro Methode immer nur 1 Testen, wenn etwas nicht funktioniert muss man es anhand der Ergebnisliste direkt erkennen können. Ohne das man es extra nochmal durch laufen lassen muss.
2. Methoden so benennen das man anhand der Testergebnisliste direkt sieht was getestet wurde, und was für ein Ergebnis erwartet wird.
Die Konvention die sehr verbreitet ist ist: MethodName_TestWith_ExpectedResult
Es kann ruhig sehr lang werden.
3. Richte dich am besten auch nach den AAA (Arrange, Act, Assert)

[TestMethod]
[ExpectedException(typeof(DoSomethingException))]
public void DoSomething_WithoutParameter_ThrowsDoSomethingException()
{
    this.TMap.DoSomething();
}

[TestMethod]
[ExpectedException(typeof(DoSomething2Exception))]
public void DoSomething2_WithoutParameter_ThrowsDoSomething2Exception()
{
    this.TMap.DoSomething2();
}

Wenn dann die erwartete Exception kommt steht es als Passed. Wenn nicht heißt es so alla:
"DoSomething_WithoutParameter_ThrowsDoSomethingException doesn't throw the expected 'DoSomethingException'"
oder wenn die falsche kommt:
"DoSomething_WithoutParameter_ThrowsDoSomethingException trows 'DoSomething2Exception', but 'DoSomethingException' was expected"

Danke mal für die lange ausführliche Antwort.

Es handelt sich hier nicht um herkömmliche UnitTests.

1. Pro Methode immer nur 1 Testen, wenn etwas nicht funktioniert muss man es anhand der Ergebnisliste direkt erkennen können. Ohne das man es extra nochmal durch laufen lassen muss.

Es ist auch nur ein Test. Die Methode muss auch nicht nochmal laufen,
es kann die Nächste sein, bei der dann ein Fehler auf tritt oder nicht.
Wenn nicht, soll eben nicht der Fehler von vorhin erkannt werden.
Es geht hier beim feststellen nicht um die Ergebnisliste,
ich brauche das einfach für den Lauf in der Methode (vl für das Arrange ...).

2. Methoden so benennen das man anhand der Testergebnisliste direkt sieht was getestet wurde, und was für ein Ergebnis erwartet wird.
Die Konvention die sehr verbreitet ist ist: MethodName_TestWith_ExpectedResult
Es kann ruhig sehr lang werden.
3. Richte dich am besten auch nach den AAA (Arrange, Act, Assert)

Das ist natürlich Sinnvoll
Und versuche ich soweit möglich auch zu machen.

Das halb möchte ich einfach IN einer Methode checken: Gabs eine Exception oder nicht bei der letzten?

Du willst also eine Abhängigkeit zwischen wei unterschiedlichen UnitTest-Methoden erzeugen? Sprich das Verhalten von Methode 2 soll abhängig sein vom Ergenis der Methode 1?

loks schrieb:

Du willst also eine Abhängigkeit zwischen wei unterschiedlichen UnitTest-Methoden erzeugen? Sprich das Verhalten von Methode 2 soll abhängig sein vom Ergenis der Methode 1?

Kann man so sehen.

Obwohl beides keine UnitTests sind insbesondere zweiteres nicht
Müsste auch so auf generell zwei Methoden anwendbar sein ....
(Und ja ich will das so falls die frage auf taucht, sonst fürde ich nicht explizit danach fragen )

Um das vl bisschen verständlicher zu machen, Methode1 wird generiert, und möglichst nichtmehr angegriffen.
Hab jetzt vl sowas in die Richung gefunden:
System.AppDomain.UnhandledException & System.AppDomain.FirstChanceException.
Allerdings weiß ich nicht ganz, ob ich da auf dem Richtigen weg bin.
PS: vl sollte ich dazu sagen, das ich bei C# seeehr neu bin.