Tak się szczęśliwie/nieszczęśliwie złożyło, że potrzebowałem coś przetestować, a nie miałem pod ręką żadnego środowiska testowego (nawet NUnit gdzieś się zapodział). Co tu począć, kusa rada, przyjdzie napisać sobie taki NUnit samemu. Niech to będzie aplikacja konsolowa o takiej treści:
class Program { static void Main(string[] args) { MyUnit.Tests.Run(); Console.ReadKey(true); } } [TestFixture] public class IntegerTest { [Test] public void Relations() { Integer a = 5, c = 5; Assert.IsTrue(a == c); Assert.IsFalse(a != c); } }
A oto implementacje klas przestrzeni nazw MyUnit, które umieszczam gdzieś w tym samym module Tests.cs
Tak wygląda wynik jeśli przejdzie testy:
A tak, jeśli nie przejdzie:
Podaje numer linii z asercją, na której się wywaliło, nazwę pliku, a także co takiego jest w tej linii pliku napisane!!!
A po co 2 asercje? Przecież sprawdzenie jednego warunku da nam odpowiedź czy drugi jest spełniony czy nie.
Wygląda dziwnie, prawda? W tym przykładzie chodziło mi o sprawdzenie czy oba operatory == i != przeciążone dla jakiejś klasy Integer działają poprawnie. Każdy z tych operatorów przeciąża się osobno (ale razem, tzn. jeśli przeciążymy jeden, to musimy też drugi), więc – teoretycznie – można to zrobić inaczej (bo na przykład łatwiej stwierdzić różność niż równość).