NUnit - jak przetestować wszystkie klasy implementujące dany interfejs

Nie zgadzam się z Jon Limjap Kiedy mówi,

Nie jest to umowa na Ani a.) jak metoda powinna być wdrożona i b.) co ta metoda powinna robić dokładnie (gwarantuje tylko Typ powrotu), dwa powody, które zbieram byłyby motywacją W chce tego rodzaju testu.

Może być wiele części Umowy, które nie zostały określone w rodzaju zwrotu. Przykład językowo-agnostyczny:

public interface List {

  // adds o and returns the list
  public List add(Object o);

  // removed the first occurrence of o and returns the list
  public List remove(Object o);

}

Twoje testy jednostkowe na LinkedList, ArrayList, CircularlyLinkedList, a wszystkie pozostałe powinny sprawdzić nie tylko, czy same listy są zwracane, ale także czy zostały odpowiednio zmodyfikowane.

Było wcześniejsze pytanie dotyczące projektu według umowy, które może pomóc wskazać właściwy kierunek na jeden ze sposobów suszenia tych testów.

Jeśli nie chcesz narzutu kontraktów, polecam platformy testowe, według tego, co Spoike zalecane:

abstract class BaseListTest {

  abstract public List newListInstance();

  public void testAddToList() {
    // do some adding tests
  }

  public void testRemoveFromList() {
    // do some removing tests
  }

}

class ArrayListTest < BaseListTest {
  List newListInstance() { new ArrayList(); }

  public void arrayListSpecificTest1() {
    // test something about ArrayLists beyond the List requirements
  }
}

To nie jest najlepsza praktyka.

Prosta prawda jest taka, że interfejs jest niczym więcej niż kontrakt, że metoda jest zaimplementowana. Jest to nie kontrakt na obu.) jak metoda powinna być wdrożona i b.) co ta metoda powinna robić dokładnie (gwarantuje tylko Typ powrotu), dwa powody, które zbieram byłyby motywacją W chce tego rodzaju testu.

Jeśli naprawdę chcesz mieć kontrolę nad implementacją metody, masz wariant:

• Implementowanie go jako metody w klasie abstrakcyjnej i dziedziczenie z niej. Nadal będziesz musiał dziedziczyć ją do konkretnej klasy, ale jesteś pewien, że jeśli nie jest to jawnie przesłonięte, ta metoda zrobi to poprawnie.
W 2009 roku, w ramach projektu, w ramach projektu, została uruchomiona nowa wersja platformy. net. net.]}

Przykład:

public static ReturnType MethodName (this IMyinterface myImplementation, SomeObject someParameter)
{
    //method body goes here
}

Każda implementacja odpowiednio odwołująca się do tej metody rozszerzenia będzie emitować dokładnie to metoda rozszerzenia, więc wystarczy ją przetestować tylko raz.

@Emperor XLII

Podoba mi się dźwięk testów kombinatorycznych w MbUnit, wypróbowałem technikę abstrakcyjnego testu interfejsu klasy bazowej z NUnit, i chociaż to działa, musisz mieć oddzielną oprawę testową dla każdego interfejsu implementowanego przez klasę (ponieważ w C# nie ma wielokrotnego dziedziczenia - chociaż można używać klas wewnętrznych, co jest całkiem fajne). W rzeczywistości jest to w porządku, może nawet korzystne, ponieważ grupuje testy dla klasy implementującej według interfejsu. Ale to byłoby dobrze, gdyby ramy były mądrzejsze. Gdybym mógł użyć atrybutu, aby oznaczyć klasę jako' oficjalną ' klasę testową dla interfejsu, a framework przeszukałby testowany zestaw pod kątem wszystkich klas implementujących interfejs i uruchomiłby na nim te testy.

Byłoby fajnie.

A może hierarchia klas [TestFixture]s? Umieść kod testu publicznego w klasie testu podstawowego i Dziedzicz go w klasach testu dziecięcego..

Podczas testowania kontraktu z interfejsem lub klasą bazową, wolę pozwolić frameworkowi testowemu automatycznie zająć się znalezieniem wszystkich implementatorów. Pozwala to skoncentrować się na testowanym interfejsie i mieć pewność, że wszystkie implementacje zostaną przetestowane, bez konieczności wykonywania wielu ręcznych implementacji.

• dla xUnit.net, stworzyłem bibliotekę Type Resolver do wyszukiwania wszystkich implementacji danego typu (xUnit.net rozszerzenia to tylko cienkie opakowanie nad funkcjonalnością typu Resolver, dzięki czemu można go dostosować do użytku w innych frameworkach).
• W MbUnit , możesz użyć CombinatorialTest z atrybutami UsingImplementations na parametrach.
• W przypadku innych frameworków użyteczny może być wspomniany wzorzec klasy bazowej Spoike .

Poza testowaniem podstaw interfejsu, powinieneś również sprawdzić, czy każda indywidualna implementacja spełnia swoje specyficzne wymagania.

Nie używam NUnit, ale przetestowałem interfejsy C++. Chciałbym najpierw przetestować klasę TestFoo, która jest podstawową implementacją, aby upewnić się, że ogólne rzeczy działają. Następnie wystarczy przetestować rzeczy, które są unikalne dla każdego interfejsu.