NUnit vs. MbUnit vs. MSTest vs. xUnit.net [zamknięte]

Istnieje wiele niezajmujących frameworków dla platformy .NET. Znalazłem to małe porównanie funkcji: http://xunit.github.io/docs/comparisons.html

Teraz mam wybrać najlepszy dla nas. Ale jak? Czy to ma znaczenie? Który z nich jest najbardziej przyszłościowy i ma przyzwoity impet? Czy powinienem dbać o funkcje? Chociaż xUnit wydaje się być najbardziej nowoczesny i specjalnie zaprojektowany dla platformy .NET, NUnit znów wydaje się być tym, który jest powszechnie akceptowany. MSTest ponownie jest już zintegrowany z Visual Studio ...

Wiem, że to stary wątek, ale pomyślałem, że oddam głos na xUnit.NET . Podczas gdy większość innych wymienionych ram testowych jest prawie taka sama, xUnit.NET zastosował dość unikalne, nowoczesne i elastyczne podejście do testowania jednostkowego. Zmienia terminologię, więc nie definiujesz już TestFixtures i Testów ... określasz Fakty i Teorie dotyczące twojego kodu, który lepiej integruje się z koncepcją testu z perspektywy TDD / BDD.

xUnit.NET jest również WYJĄTKOWO rozszerzalny. Klasy atrybutów FactAttribute i TraitAttribute nie są zapieczętowane i zapewniają nadające się do zastąpienia podstawowe metody, które dają dużą kontrolę nad tym, w jaki sposób metody te atrybuty powinny być wykonywane. Podczas gdy xUnit.NET w swojej domyślnej formie umożliwia pisanie klas testowych, które są podobne do urządzeń testowych NUnit z ich metodami testowymi, nie jesteś ograniczony do tej formy testowania jednostkowego. Możesz dowolnie rozszerzać ramy, aby obsługiwały specyfikacje Concern / Context / Observation w stylu BDD, jak pokazano tutaj .

xUnit.NET obsługuje również testowanie w stylu dopasowania bezpośrednio po wyjęciu z pudełka dzięki swojemu atrybutowi Teoria i odpowiednim atrybutom danych. Dopasowane dane wejściowe mogą być ładowane z programu Excel, bazy danych, a nawet niestandardowego źródła danych, takiego jak dokument programu Word (poprzez rozszerzenie podstawowego atrybutu danych). Pozwala to na wykorzystanie jednej platformy testowej do testów jednostkowych i testów integracyjnych, które może być ogromny w zmniejszaniu zależności od produktu i wymaganego szkolenia.

Inne podejścia do testowania można również wdrożyć za pomocą xUnit.NET ... możliwości są dość nieograniczone. W połączeniu z inną, bardzo perspektywiczną frakcją, Moq , oba tworzą bardzo elastyczną, rozszerzalną i potężną platformę do wdrażania automatycznych testów.

NUnit jest prawdopodobnie najbardziej obsługiwany przez narzędzia innych firm. To także trwało dłużej niż pozostałe trzy.

Osobiście nie dbam zbytnio o ramy testów jednostkowych, kpiny z bibliotek są o wiele ważniejsze (i blokują cię znacznie więcej). Wybierz jeden i trzymaj się go.

Nie poszedłbym z MSTest. Chociaż jest to prawdopodobnie najbardziej przyszły dowód na to, że frameworki oparte są na Microsoft, nie jest to najbardziej elastyczne rozwiązanie. Nie będzie działać samodzielnie bez kilku hacków. Dlatego uruchomienie go na serwerze kompilacji innym niż TFS bez instalowania programu Visual Studio jest trudne. Tester-runner działający w studiu wizualnym jest w rzeczywistości wolniejszy niż Testdriven.Net + jakikolwiek inny framework. A ponieważ wydania tego frameworka są powiązane z wydaniami Visual Studio, jest mniej aktualizacji, a jeśli musisz pracować ze starszym VS, jesteś przywiązany do starszego MSTest.

Nie sądzę, żeby miało to duże znaczenie, z których innych frameworków korzystasz. Przełączanie się między nimi jest naprawdę łatwe.

Osobiście korzystam z XUnit.Net lub NUnit w zależności od preferencji moich współpracowników. NUnit jest najbardziej standardowym. XUnit.Net to najcieńsza platforma.

Rozważ uzupełnienie, a nie zastąpienie MSTest inną strukturą testową. Możesz zachować integrację Visual Studio MSTest, korzystając jednocześnie z bardziej kompleksowych ram testowych.

Na przykład używam xUnit z MSTest. Dodaj odwołanie do zestawu xUnit.dll i po prostu zrób coś takiego. O dziwo, to po prostu działa!

using Microsoft.VisualStudio.TestTools.UnitTesting;
using Assert = Xunit.Assert;  // <-- Aliasing the Xunit namespace is key

namespace TestSample
{
    [TestClass]
    public class XunitTestIntegrationSample
    {
        [TestMethod]
        public void TrueTest()
        {
            Assert.True(true);  // <-- this is the Xunit.Assert class
        }

        [TestMethod]
        public void FalseTest()
        {
            Assert.False(true);
        }
    }
}

Nunit nie działa dobrze z projektami w trybie mieszanym w C ++, więc musiałem go upuścić

Nie jest to wielka sprawa na małą skalę / osobista, ale może szybko stać się większą transakcją na większą skalę. Mój pracodawca jest dużym sklepem Microsoft, ale z wielu powodów nie chce / nie może dokonać zakupu w Team System / TFS. Obecnie używamy Subversion + Orcas + MBUnit + TestDriven.NET i działa dobrze, ale uzyskanie TD.NET było ogromnym problemem. Wrażliwość wersji MBUnit + TestDriven.NET jest również dużym problemem, a posiadanie jednej dodatkowej komercyjnej rzeczy (TD.NET) do legalnego przeglądu i zamówień w celu obsługi i zarządzania, nie jest banalne. Moja firma, podobnie jak wiele innych firm, jest gruba i zadowolona z modelu subskrypcji MSDN i po prostu nie jest przyzwyczajona do obsługi jednorazowych zamówień dla setek programistów. Innymi słowy, w pełni zintegrowana oferta MS, choć zdecydowanie nie zawsze najlepsza z możliwych, jest moim zdaniem znaczącą wartością dodaną.

Myślę, że pozostaniemy przy obecnym kroku, ponieważ to działa i już przebrnęliśmy organizacyjnie garb, ale na pewno żałuję, że stwardnienie rozsiane nie miało atrakcyjnej oferty w tej przestrzeni, abyśmy mogli skonsolidować i nieco uprościć nasz zestaw deweloperów.

To nie jest wielka sprawa, dość łatwo się między nimi przełączać. Zintegrowanie MSTest też nie jest wielkim problemem, wystarczy pobrać testdriven.net.

Tak jak poprzednia osoba powiedziała, że ​​wybrał kpinę, moim ulubionym w tej chwili jest Moq.