Hallo,
ich schreibe gerade Unit Tests für Methoden die unter CodeContracts stehen.

[ExpectedException(typeof(ContractException))]

kann leider nicht angegeben werden weil die ContractException internal ist.
weiß jemand eine Alternative?

Hallo Rainer,

ich weiß leider keine Alternative, aber ich habe die Lösung

The Automated Tester - NUnit internal classes
Stichwort: MSDN - InternalsVisibleToAttribute

Viele Grüße
Timo

Hallo Timo,
das geht leider nicht, denn dafür müßte ich das InternalsVisibleTo Attribut in die AssemblyInfo der CodeContracts-Library einsetzen, aber die steht mir nicht zur Verfügung.

Ich benutze jetzt einen WorkAround. Es funktioniert, ist aber umständlich und statisch.

1. In der Testklasse abonniere ich das ContractFailed Event.

[AssemblyInitialize]
public static void AssemblyInitialize(TestContext tc)
{
   Contract.ContractFailed += OnContractFailed;
}

2. Ich definiere eine klassenweite Hilfsvariable vom Typ ContractFailedEventArgs.

private static ContractFailedEventArgs contractFailedEventArgs;

3. Ich schreibe folgenden EventHandler:

      static void OnContractFailed(object sender, ContractFailedEventArgs e)
      {
         e.SetHandled();
         contractFailedEventArgs = e;
         Console.WriteLine(e.Condition + ": " + e.Message);
      }

4. Die Exception-Message, die an die Hilfsvariable übergeben wurde, kann im Test mit einem Sollwert verglichen werden.

      [TestMethod]
      public void EnsuresAndResultDemoTest()
      {
         var target = new SomeClass();
         int someValue = 2;
         target.EnsuresAndResultDemo(someValue);
         Assert.AreEqual("Postcondition failed: Contract.Result<double>() >= 10",
            contractFailedEventArgs.Message);
      }

Dieser letzte Schritt ist das umständliche und unflexible an der Sache. Um den Sollwert zu ermitteln, muß ich den Test erst einmal "nackt" laufen lassen, um zu erfahren wie genau die Exception Message denn lautet. Die kopiere ich mir dann in den Assert. Ziemlich blöde Sache.

Hallo Rainer,

ok, ok, ich geb mich geschlagen, wenn Du auf die Contracts keinen Einfluss hast?!

-> Naja da fällt mir in der Tat nur Reflection ein, was aber auch nur dann funktioniert, wenn die Struktur es vorgibt (z.B. alle internal Exception-Klassen haben im Namen "Exception").
Der Workaround ist wirklich ein wenig hässlich.

Andere Frage:
Kannst Du im Test nicht eine "System.Exception" erwarten, und dann anhand dessen Namen bestimmen, ob die richtige Exception geschmissen wurde (ok, auch hässlich, aber kürzer als Dein Workaround)?

Grüße
Timo

Hallo Timo,
ExpectedException(typeof(Exception)) geht nicht. Es kommt zu folgender Fehlermeldung:

UTA017: ContractTests.SomeClassTest.EnsuresAndResultDemoTest has invalid ExpectedException attribute. The type must inherit from Exception.

Ich denke das ist "by Design", denn so wie man bei einem Try/Catch-Block nach Möglichkeit spezifische Exceptions abfangen soll, ist es auch bei Unit Tests angebracht.
Du hast mir aber den Schubs in die korrekte Richtung gegeben. Der Test sieht jetzt so aus und macht was er soll:

      public void EnsuresAndResultDemoTest()
      {
         var target = new SomeClass();
         int someValue = 2;
         try
         {
            target.EnsuresAndResultDemo(someValue);
         }
         catch(Exception exc)
         {
            Console.WriteLine(exc.GetType().Name);
            Assert.IsTrue(exc.GetType().Name == "ContractException");
            return;
         }
         Assert.Fail("ContractException has not been thrown.");
      }

Weil SetHandled das Werfen der ContractException abstellt, muß nur der EventHandler leicht modifiziert werden.

      static void OnContractFailed(object sender, ContractFailedEventArgs e)
      {
         e.SetHandled();
         Console.WriteLine(e.Condition + ": " + e.Message);
         e.SetUnwind();
      }

Mit SetUnwind wird die Exception wieder geworfen.

Ich hab mal irgendwo gelesen daß Try/Catch in einer Testmethode vermieden werden sollte (eben auch weil es ein Zeichen für unwägbaren code under test ist), aber das hier könnte ein Ausnahmefall sein.

Falls du CodeContracts nicht kennst, schau dir das API mal an, ist ne tolle Sache.
CodeContracts

Ausführlicher hier:
CodeContracts

Es gibt zwei kommerzielle Lizenzen und eine freie akademische, die aber ziemlich versteckt ist. Darum hier ein Extra-Link.

Download der freien academic version mit static checker.

CodeContracts ist auch im .net Framework 4 enthalten.

Hallo Rainer nochmal,

Falls du CodeContracts nicht kennst

Ja und nein. Ich kenne das Prinzip von CodeContracts, allerdings wusste ich nicht, dass da was im FW 4.0 von Microsoft kommt. Bisher habe ich nur Custom-Umsetzungen oder Third-Party hierzu gefunden/verwendet.

Insofern: vielen Dank für die Informativen Links.

Übrigens hatte ich insgeheim eine "Try-Catch" Verwendung gemeint (ich hatte es allerdings nicht direkt erwähnt). Ich denke, dass "Try-Catch" hier in NUnits vertretbar ist. Wir im Projekt verwenden dieses Konstrukt sogar recht häufig, z.b. auch um allgemeine Runtime-Exceptions wie z.B. "Datenbank aktuell nicht erreichbar" abzufangen. Dann kann man nämlich eine eigene Exception über NUnit ausgeben lassen, die z.B. wie folgt aussieht: "Konnte Methode xyz nicht erfolgreich testen, weil DB Kaputt !"

Grüße
Timo

Timo Rehl:

z.b. auch um allgemeine Runtime-Exceptions wie z.B. "Datenbank aktuell nicht erreichbar" abzufangen. Dann kann man nämlich eine eigene Exception über NUnit ausgeben lassen, die z.B. wie folgt aussieht: "Konnte Methode xyz nicht erfolgreich testen, weil DB Kaputt !"

Das macht Sinn.

Ich habe aus der Lösung kurzerhand ein Snippet gebastelt. Vielleicht kann es anderen auch behilflich sein.

Unter den NUnit Extensions (oder ist es mittlerweile schon mit drinnen) gibt es einen Funktion die nennt sich Assert.Throws(...) die genau das macht ;-)

unter den anderen Testframeworks gibt es glaube ich ähnliche Methoden. Bei xUnit.BDDextensions ist es ShouldThrow(..)

Ich benutze Gallio - habe gerade mal nachgeschaut, MBUnit hat auch Assert.Throws im Gepäck. Allerdings erwartet die Methode, wie sollte es auch anders sein, den Typ der Exception. Damit steht man als Entwickler wieder vor dem gleichen Dillema wie bei dem ExpectedException-Attribut von MSTest.
Ich verstehe nicht, warum Microsoft die ContractException-Klasse internal gemacht hat. Hoffentlich ist das in der .net 4 Version anders.

Hallo zusammen,

Ich verstehe nicht, warum Microsoft die ContractException-Klasse internal gemacht hat.

Das verstehe ich in der Tat auch nicht. Gerade Exceptions sind "global" handzuhaben. Irgendwo kommen die Exceptions doch durchgedrungen, und dann sollte man auch Zugriff darauf haben.
Hier würde ich das auch als Designfehler sehen, das ist meiner Meinung nach der falsche Weg von Kapselung.

Grüße
Timo