2016-04-07 31 views
7

Obecnie przepisuję niektóre testy jednostkowe, aby użyć NUnit 3 zamiast NUnit 2 i trzeba zmienić niektóre asserts na asserts oparte na ograniczeniach. Mam następujący twierdzi:Zwiększenie czytelności, aby potwierdzić IsNotNullOrEmpty za pomocą opartych na ograniczeniach twierdzeń

Assert.IsNullOrEmpty(result); 

że mam zmienione na:

Assert.That(result, Is.Null.Or.Empty); 

Jednakże, nie jestem całkowicie zadowolony z czytelności podczas dochodzenia IsNotNullOrEmpty:

Assert.That(result, Is.Not.Null.And.Not.Empty); 

My obecną sugestią jest utworzenie następującej klasy statycznej:

public static class Text 
{ 
    public static EmptyConstraint IsNullOrEmpty => Is.Null.Or.Empty; 

    public static EmptyConstraint IsNotNullOrEmpty => Is.Not.Null.And.Not.Empty; 
} 

Zastosowanie:

Assert.That(result, Text.IsNotNullOrEmpty); 

ta zapewnia lepszą czytelność kosztem wprowadzenia niestandardowy ograniczenie. Czy istnieje standardowy sposób tworzenia tego samego potwierdzenia, czy powinienem zamiast tego nadal używać Is.Not.Null.And.Not.Empty?

+0

Na to pytanie można odpowiedzieć obiektywnie. Zmieniono ciało, aby ponownie zadać pytanie w sposób nie subiektywny; głosowanie na ponowne otwarcie. – dasblinkenlight

Odpowiedz

7

Twoja asercja dla Is.Null.Or.Empty czyta doskonale bez klasy Test. Co więcej, kiedy to stwierdzenie nie powiedzie się, wiesz dokładnie, co się stało: masz ważny obiekt, który nie jest pusty.

Kwestie, które widzę z wersją negacji "DeMorganized", tj. Is.Not.Null.And.Not.Empty, są zbyt długie i nie czytają tak ładnie, jak robi to Is.Null.Or.Empty.

Jednak zamiast tworzenia oddzielnego ograniczenie dla niej, chciałbym stwierdzić, jego poszczególne części, tj

Assert.That(result, Is.Not.Null); 
Assert.That(result, Is.Not.Empty); 

Powodem zrobiłbym to tak jest, że te dwa warunki niepowodzenia nie zachodzą na siebie, tj result może być null, lub może być pusty, ale nie może być jednocześnie obu. Pojedyncza asercja złożona nie rozróżnia tych dwóch sytuacji, więc kończy się wyszukiwaniem debuggera, aby sprawdzić, czy jest on pusty.

Oddzielne twierdzenia z drugiej strony mówią dokładnie, co się stanie, pozostając bardzo czytelne. "Kosztują" cię jedną dodatkową linię za każde twierdzenie; Myślę, że jest to rozsądny koszt uzyskania dokładniejszych informacji na temat potencjalnych awarii.