Testuj swój kod, Nie język.

Test jednostkowy jak:

Integer i = new Integer(7);
assert (i.instanceOf(integer));

Jest przydatna tylko wtedy, gdy piszesz kompilator i istnieje niezerowa szansa, że twoja metoda instanceof nie działa.

Nie testuj rzeczy, które możesz wymusić na języku. W Twoim przypadku skupiłbym się na metodach uwierzytelniania i zapisywania - i pisałbym testy, które upewniły się, że mogą obsługiwać wartości null w dowolnym lub wszystkich tych polach z wdziękiem.

Dzięki temu zacząłem testować jednostki i byłem bardzo szczęśliwy

Potem musieliśmy przepisać ważny fragment kodu w naszym programie księgowym. Ta część była bardzo złożona, ponieważ obejmowała wiele różnych scenariuszy. Część, o której mówię, to sposób na opłacenie już wprowadzonych faktur sprzedaży i / lub zakupu do systemu księgowego.

Po prostu nie wiedziałem, jak zacząć go kodować, ponieważ było tak wiele różnych opcji płatności. Faktura może wynosić $100, ale klient przesłał tylko $ 99 . Być może wysłałeś faktury sprzedaży do klienta, ale również dokonałeś zakupu od tego klienta. Więc sprzedałeś go za $ 300, ale kupiłeś za $100. Możesz oczekiwać, że twój Klient zapłaci ci $200, aby uregulować saldo. A co jeśli sprzedasz za $500, a Klient zapłaci Ci tylko $ 250?

Więc miałem bardzo złożony problem do rozwiązania z wieloma możliwościami, że jeden scenariusz byłby idealny, ale byłby błędny w innym rodzaju kombinacji invocie/płatności.

Tu na ratunek przyszły testy jednostkowe.

Zacząłem pisać (w kodzie testowym) metodę tworzenia listy faktur, zarówno dla sprzedaży, jak i zakupów. Następnie napisałem drugą metodę tworzenia rzeczywistej płatności. Normalnie użytkownik wprowadzałby te informacje przez interfejs użytkownika.

Then Stworzyłem pierwszy TestMethod, testując bardzo prostą płatność jednej faktury bez żadnych rabatów płatności. Cała akcja w systemie wydarzyłaby się, gdy wpłata Bankowa zostałaby zapisana w bazie danych. Jak widać utworzyłem fakturę, utworzyłem płatność (transakcję bankową) i zapisałem transakcję na dysku. W moich oświadczeniach wpisuję, jakie powinny być prawidłowe numery kończące się w transakcji bankowej i w powiązanej fakturze. Sprawdzam liczbę płatności, kwoty płatności, kwota rabatu i saldo faktury po transakcji.

Po uruchomieniu testu poszedłem do bazy danych i sprawdziłem dwukrotnie, czy jest tam to, czego się spodziewałem.

Po napisaniu testu zacząłem kodować metodę płatności (część klasy BankHeader). W kodowaniu zawracałem sobie tylko głowę kodem, aby przejść pierwszy test. Nie myślałem jeszcze o innych, bardziej złożonych scenariuszach.

Uruchomiłem pierwszy test, naprawiłem mały błąd, dopóki mój test nie pasuję.

Potem zacząłem pisać drugi test, tym razem z rabatem na płatności. Po napisaniu testu zmodyfikowałem metodę płatności, aby wspierać rabaty.

Podczas testowania poprawności z rabatem płatności, przetestowałem również prostą płatność. Oba testy powinny oczywiście przejść.

Potem pracowałem nad bardziej złożonymi scenariuszami.

1) pomyśl o nowym scenariuszu

2) Napisz test dla tego scenariusza

3) Run that pojedynczy test, aby sprawdzić, czy przejdzie

4) gdyby tak nie było, debugowałbym i modyfikował kod, aż przejdzie.

5) modyfikując kod kontynuowałem wszystkie testy

W ten sposób udało mi się stworzyć bardzo skomplikowaną metodę płatności. Bez testów jednostkowych nie wiedziałem, jak rozpocząć kodowanie, problem wydawał się przytłaczający. Z testowaniem mogłem zacząć od prostej metody i rozszerzać ją krok po kroku z zapewnieniem, że prostsze scenariusze nadal będą działać.

I ' m pewnie, że korzystanie z testów jednostkowych zaoszczędziło mi kilka dni (lub tygodni) kodowania i mniej więcej gwarantuje poprawność mojej metody.

Jeśli później pomyślę o nowym scenariuszu, mogę po prostu dodać go do testów, aby sprawdzić, czy działa, czy nie. Jeśli nie mogę zmodyfikować kod, ale nadal upewnij się, że inne scenariusze nadal działają poprawnie. Pozwoli to zaoszczędzić wiele dni w fazie konserwacji i naprawiania błędów.

Tak, nawet testowany kod może nadal mieć błędy, jeśli użytkownik zrobi to, co zrobiłeś nie myśl o nim ani nie powstrzymuj go przed zrobieniem

Poniżej kilka testów, które stworzyłem, aby przetestować moją metodę płatności.

public class TestPayments
{
    InvoiceDiaryHeader invoiceHeader = null;
    InvoiceDiaryDetail invoiceDetail = null;
    BankCashDiaryHeader bankHeader = null;
    BankCashDiaryDetail bankDetail = null;



    public InvoiceDiaryHeader CreateSales(string amountIncVat, bool sales, int invoiceNumber, string date)
    {
        ......
        ......
    }

    public BankCashDiaryHeader CreateMultiplePayments(IList<InvoiceDiaryHeader> invoices, int headerNumber, decimal amount, decimal discount)
    {
       ......
       ......
       ......
    }


    [TestMethod]
    public void TestSingleSalesPaymentNoDiscount()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("119", true, 1, "01-09-2008"));
        bankHeader = CreateMultiplePayments(list, 1, 119.00M, 0);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(1, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(119M, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(0M, bankHeader.BankCashDetails[0].Payments[0].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
    }

    [TestMethod]
    public void TestSingleSalesPaymentDiscount()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("119", true, 2, "01-09-2008"));
        bankHeader = CreateMultiplePayments(list, 2, 118.00M, 1M);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(1, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(118M, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(1M, bankHeader.BankCashDetails[0].Payments[0].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
    }

    [TestMethod]
    [ExpectedException(typeof(ApplicationException))]
    public void TestDuplicateInvoiceNumber()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("100", true, 2, "01-09-2008"));
        list.Add(CreateSales("200", true, 2, "01-09-2008"));

        bankHeader = CreateMultiplePayments(list, 3, 300, 0);
        bankHeader.Save();
        Assert.Fail("expected an ApplicationException");
    }

    [TestMethod]
    public void TestMultipleSalesPaymentWithPaymentDiscount()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("119", true, 11, "01-09-2008"));
        list.Add(CreateSales("400", true, 12, "02-09-2008"));
        list.Add(CreateSales("600", true, 13, "03-09-2008"));
        list.Add(CreateSales("25,40", true, 14, "04-09-2008"));

        bankHeader = CreateMultiplePayments(list, 5, 1144.00M, 0.40M);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(4, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(118.60M, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(400, bankHeader.BankCashDetails[0].Payments[1].PaymentAmount);
        Assert.AreEqual(600, bankHeader.BankCashDetails[0].Payments[2].PaymentAmount);
        Assert.AreEqual(25.40M, bankHeader.BankCashDetails[0].Payments[3].PaymentAmount);

        Assert.AreEqual(0.40M, bankHeader.BankCashDetails[0].Payments[0].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[1].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[2].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[3].PaymentDiscount);

        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[1].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[2].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[3].InvoiceHeader.Balance);
    }

    [TestMethod]
    public void TestSettlement()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("300", true, 43, "01-09-2008")); //Sales
        list.Add(CreateSales("100", false, 6453, "02-09-2008")); //Purchase

        bankHeader = CreateMultiplePayments(list, 22, 200, 0);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(2, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(300, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(-100, bankHeader.BankCashDetails[0].Payments[1].PaymentAmount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[1].InvoiceHeader.Balance);
    }

Jeśli naprawdę są trywialne, to nie trudź się testowaniem. Np. jeśli są one zaimplementowane w ten sposób;

public class User
{
    public string Username { get; set; }
    public string Password { get; set; }
}

Jeśli, z drugiej strony, robisz coś mądrego (jak szyfrowanie i deszyfrowanie hasła w getter/setter) to daj mu test.

Zasada jest taka, że musisz przetestować każdy kawałek logiki, który piszesz. Jeśli zaimplementowałeś jakąś konkretną funkcjonalność w getterach i seterach, myślę, że warto je przetestować. Jeśli przypisują wartości tylko do niektórych prywatnych pól, nie przejmuj się.

To pytanie wydaje się być pytaniem, gdzie rysuje się linię, jakie metody są testowane, a które nie.

Settery i gettery do przypisywania wartości zostały stworzone z myślą o spójności i przyszłym wzroście i przewidywaniu, że w przyszłości setter / getter może przekształcić się w bardziej złożone operacje. Sensowne byłoby wprowadzenie testów jednostkowych tych metod, również ze względu na spójność i przyszły wzrost.

Niezawodność kodu, szczególnie podczas przechodzenia zmian, aby dodać dodatkową funkcjonalność, jest głównym celem. Nie jestem świadomy, że ktoś kiedykolwiek został zwolniony za włączenie setterów / getterów do metodologii testowania, ale jestem pewien, że istnieją ludzie, którzy chcieliby przetestować metody, które ostatnio byli świadomi lub mogą przypomnieć, że były proste owijarki set / get, ale to już nie było.

Może inny członek zespołu rozszerzył metody set / get o logikę, która teraz wymaga przetestowania, ale nie wtedy stwórz testy. Ale teraz Twój kod wywołuje te metody i nie jesteś świadomy, że się zmieniły i wymagają dogłębnych testów, a testy, które wykonujesz w rozwoju i kontroli jakości, nie wywołują wady, ale prawdziwe dane biznesowe pierwszego dnia wydania powodują ją.

Dwaj koledzy z drużyny będą teraz dyskutować nad tym, kto upuścił piłkę i nie poddał się testom jednostkowym, gdy zestaw / zostanie zmieniony na logikę, która może się nie udać, ale nie jest objęta testem jednostkowym. Zespół, który pierwotnie napisał set / gets będzie miał łatwiejszy czas wychodzenia z tego czyszczenia, jeśli testy zostały zaimplementowane od pierwszego dnia na simple set / gets.

Moja opinia jest taka, że kilka minut "zmarnowanego" czasu obejmującego wszystkie metody testami jednostkowymi, nawet banalnymi, może zaoszczędzić dni bólu głowy w dół drogi i utraty pieniędzy / reputacji firmy i utraty czyjejś pracy.

A fakt, że owijałeś trywialne metody testami jednostkowymi może być zauważony przez tego młodszego kolegę z drużyny, gdy zmienią trywialne metody na nietrywialne i skłaniają do aktualizacji testu, a teraz nikt nie ma kłopotów, ponieważ wada została powstrzymana przed dotarciem do produkcji.

Sposób, w jaki kodujemy, i dyscyplina, którą widać z naszego kodu, może pomóc innym.

Kolejna kanoniczna odpowiedź. To chyba od Rona Jeffriesa:

Testuj tylko kod, który chcesz uruchomić.

Testowanie kodu kotła to strata czasu, ale jak mówi Slavo, jeśli dodasz efekt uboczny do getterów/setterów, powinieneś napisać test, który będzie towarzyszył tej funkcjonalności.

Jeśli robisz test-driven development, powinieneś najpierw napisać umowę(np. interfejs), a następnie napisać test (y), aby wykonać ten interfejs, który dokumentuje oczekiwane wyniki / zachowanie. Następnie napisz swoje metody samodzielnie, bez dotykania kodu w testach jednostkowych. Na koniec Pobierz kod narzędzie coverage i upewnij się, że testy wykonują wszystkie ścieżki logiczne w kodzie.

Naprawdę trywialny kod, taki jak gettery i settery, które nie mają dodatkowego zachowania niż ustawienie pola prywatnego, jest przesadą do przetestowania. W 3.0 C# ma nawet trochę cukru składniowego, w którym kompilator zajmuje się prywatnym polem, więc nie trzeba go programować.

Zazwyczaj piszę wiele bardzo prostych testów weryfikujących zachowanie, jakich oczekuję od moich zajęć. Nawet jeśli to proste rzeczy jak dodawanie dwóch liczb. Często przełączam się między pisaniem prostego testu a pisaniem kilku linijek kodu. Powód bo to jest to, że wtedy mogę zmienić kod bez obawy, że złamałem rzeczy, o których nie myślałem.

Powinieneś wszystko przetestować. W tej chwili masz gettery i setery, ale pewnego dnia możesz je nieco zmienić, może zrobić walidację lub coś innego. Testy, które dziś napiszesz, zostaną wykorzystane jutro, aby upewnić się, że wszystko działa jak zwykle. Pisząc test, powinieneś zapomnieć o rozważaniach typu "teraz jest trywialnie". W kontekście zwinnym lub testowym należy przetestować przy założeniu przyszłej refaktoryzacji. Poza tym, czy próbowałeś wprowadzić naprawdę dziwne wartości, takie jak ekstremalnie długie ciągi, czy inne " złe " treści? Powinieneś... nigdy nie zakładaj, jak bardzo twój kod może być nadużywany w przyszłości.

Ogólnie uważam, że pisanie rozbudowanych testów użytkowników jest z jednej strony wyczerpujące. Z drugiej strony, choć zawsze daje bezcenny wgląd w to, jak powinna działać Twoja aplikacja i pomaga odrzucić łatwe (i fałszywe) założenia(takie jak: nazwa użytkownika zawsze będzie miała mniej niż 1000 znaków).

Dla prostych modułów, które mogą skończyć się w zestawie narzędzi lub w projekcie typu open source, powinieneś przetestować jak najwięcej, włączając trywialne gettery i settery. Rzeczą, którą chcesz pamiętać, jest to, że generowanie testu jednostkowego podczas pisania konkretnego modułu jest dość proste i proste. Dodawanie getterów i setterów jest minimalnym kodem i może być obsługiwane bez większego namysłu. Jednak po umieszczeniu kodu w większym systemie ten dodatkowy wysiłek może uchronić Cię przed zmiany w systemie bazowym, takie jak zmiany typu w klasie bazowej. Testowanie everthing jest najlepszym sposobem na regresję, która jest kompletna.

Nie zaszkodzi pisać testów jednostkowych dla getterów i seterów. W tej chwili mogą po prostu robić pola get / sets pod maską, ale w przyszłości możesz mieć logikę walidacji lub zależności między właściwościami, które należy przetestować. Łatwiej jest to napisać teraz, gdy myślisz o tym, a następnie pamiętając, aby go zmodernizować, jeśli ten czas kiedykolwiek nadejdzie.

Ogólnie rzecz biorąc, jeśli metoda jest zdefiniowana tylko dla pewnych wartości, testuj wartości na i na granicy tego, co jest dopuszczalne. Innymi słowy, upewnij się, że twoja metoda robi to, co powinna, , ale nic więcej . Jest to ważne, ponieważ kiedy masz zamiar zawieść, chcesz zawieść wcześnie.

W hierarchii dziedziczenia, upewnij się, aby sprawdzić zgodność LSP .

Testowanie domyślnych getterów i seterów nie wydaje mi się zbyt przydatne, chyba że planuję później przeprowadzić weryfikację.

Jak rozumiem testy jednostkowe w kontekście zwinnego rozwoju, Mike, tak, musisz przetestować gettery i settery (zakładając, że są publicznie widoczne). Cała koncepcja testów jednostkowych polega na przetestowaniu jednostki oprogramowania, która w tym przypadku jest klasą, jako czarna skrzynka . Ponieważ gettery i settery są widoczne na zewnątrz, musisz je przetestować wraz z uwierzytelnianiem i zapisywaniem.

Jeśli metody Authenticate i Save używają właściwości, to testy pośrednio dotkną właściwości. Tak długo, jak właściwości są tylko zapewnienie dostępu do danych, a następnie wyraźne testy nie powinny być konieczne(chyba że idziesz na 100% pokrycie).

Przetestowałbym Twoje getery i setery. W zależności od tego, kto pisze kod, niektórzy ludzie zmieniają znaczenie metod getter/setter. Widziałem inicjalizację zmiennych i inne walidacje jako część metod getter. W celu przetestowania tego typu rzeczy, chcielibyśmy testy jednostkowe obejmujące ten kod wyraźnie.

Osobiście chciałbym "przetestować wszystko, co może się złamać" i prosty getter (lub nawet lepsze właściwości auto) nie złamie. Nigdy nie miałem prostej deklaracji powrotu i nigdy nie miałem dla nich testu. Jeśli getterzy mają w sobie obliczenia lub jakąś inną formę wypowiedzi, z pewnością dodałbym dla nich testy.

Osobiście używam Moq jako wzorcowego frameworka obiektu, a następnie sprawdzam, czy mój obiekt wywołuje otaczające obiekty tak, jak powinien.

Musisz pokryć wykonanie każdej metody klasy UT i sprawdzić wartość zwracaną metody. Obejmuje to gettery i settery, szczególnie w przypadku, gdy członkowie (właściwości) są złożonymi klasami, które wymagają dużej alokacji pamięci podczas ich inicjalizacji. Wywołaj setter z bardzo dużym ciągiem znaków np. (lub czymś z symbolami greckimi) i sprawdź, czy wynik jest poprawny (nie okrojony, kodowanie jest dobre np.)

W przypadku prostych liczb całkowitych, które również mają zastosowanie - co się stanie, jeśli zdasz long zamiast integer? Dlatego piszesz UT:)

Nie testowałbym rzeczywistego ustawienia właściwości. Byłbym bardziej zaniepokojony tym, jak te właściwości zostają zaludnione przez konsumenta i czym je wypełniają. W przypadku jakichkolwiek testów musisz rozważyć ryzyko wraz z czasem / kosztem testów.

Powinieneś przetestować "każdy nietrywialny blok kodu" używając testów jednostkowych w miarę możliwości.

Jeśli Twoje właściwości są trywialne i jest mało prawdopodobne, że ktoś wprowadzi w nim błąd, to powinno być bezpiecznie nie testować ich jednostkowo.

Twoje metody Authenticate() i Save () wyglądają jak dobre kandydatury do testów.

Najlepiej byłoby, gdybyś zrobił testy jednostkowe podczas pisania klasy. Tak właśnie powinieneś to zrobić, korzystając z Test Driven Development. Testy dodawane są podczas implementacji każdego punktu funkcji, upewniając się, że pokrywasz również przypadki brzegowe testem.

Pisanie testów jest o wiele bardziej bolesne, ale wykonalne.

Oto co bym zrobił na Twoim miejscu:

1. napisz podstawowy zestaw testów testujących podstawową funkcję.
2. Pobierz NCover i uruchom go na twoje testy. Twój zasięg testu będzie prawdopodobnie około 50% w tym momencie.
3. dodawaj testy, które pokrywają Twoje edge-cases, aż uzyskasz pokrycie około 80% -90%

To powinno dać ci dobry zestaw testów jednostkowych, które będą działać jako dobry bufor przeciwko regresji.

Jedynym problemem w tym podejściu jest to, że kod musi być zaprojektowany , aby mógł być testowany w ten sposób. Jeśli wcześniej popełniłeś jakieś błędy w sprzęganiu, nie będziesz w stanie się naćpać pokrycie bardzo łatwo.

Dlatego tak ważne jest, aby napisać testy przed napisaniem kodu. Zmusza do pisania kodu, który jest luźno sprzężony.

Nie testuj oczywiście działającego kodu (kotła). Więc jeśli Twoje settery i gettery są po prostu "propertyvalue = value" I "return propertyvalue", nie ma sensu tego testować.

Parzyste get / set mogą mieć dziwne konsekwencje, w zależności od tego, jak zostały zaimplementowane, więc powinny być traktowane jako metody.

Każdy z tych testów będzie musiał określić zestawy parametrów dla właściwości, definiując zarówno akceptowalne, jak i niedopuszczalne właściwości, aby zapewnić, że wywołania zwrócą / zawiodą w oczekiwany sposób.

Należy również pamiętać o zabezpieczeniach, jako przykład SQL injection, i przetestować je.

Więc tak, musisz się martwić o testowanie właściwości.

Uważam, że testowanie getterów i setterów jest głupie, gdy wykonują tylko prostą operację. Osobiście nie piszę skomplikowanych testów jednostkowych, aby pokryć wszelkie wzorce użytkowania. Staram się napisać wystarczająco dużo testów, aby upewnić się, że obsłużyłem normalne zachowanie wykonania i tyle przypadków błędów, jakie mogę wymyślić. Napiszę więcej testów jednostkowych jako odpowiedź na zgłoszenia błędów. Używam testu jednostkowego, aby upewnić się, że kod spełnia wymagania i ułatwić przyszłą modyfikację. Czuję się o wiele bardziej skłonny do zmiany kodu, gdy wiem że jeśli coś złamię, test się nie powiedzie.

Napisałbym test na wszystko, co piszesz kod, który można przetestować poza interfejsem GUI.

Zazwyczaj każda logika, którą piszę, która ma dowolną logikę biznesową, którą umieszczam w innej warstwie lub warstwie logiki biznesowej.

Wtedy pisanie testów na wszystko, co coś robi, jest łatwe do zrobienia.

Najpierw napisz test jednostkowy dla każdej publicznej metody w "warstwie logiki biznesowej".

Gdybym miał taką klasę:

   public class AccountService
    {
        public void DebitAccount(int accountNumber, double amount)
        {

        }

        public void CreditAccount(int accountNumber, double amount)
        {

        }

        public void CloseAccount(int accountNumber)
        {

        }
    }

The first thing I would zrobić zanim napiszę jakiś kod wiedząc, że mam te działania do wykonania byłoby rozpocząć pisanie testów jednostkowych.

   [TestFixture]
    public class AccountServiceTests
    {
        [Test]
        public void DebitAccountTest()
        {

        }

        [Test]
        public void CreditAccountTest()
        {

        }

        [Test]
        public void CloseAccountTest()
        {

        }
    }

Napisz swoje testy, aby zweryfikować kod, który napisałeś, aby coś zrobić. Jeśli zmienisz zbiór rzeczy i zmienisz coś w każdym z nich, napisz test, który zrobi to samo i potwierdzi, że faktycznie się stało.

Istnieje wiele innych podejść, a mianowicie Behavioir Driven Development (BDD), które są bardziej zaangażowane i nie są świetne zacznij od umiejętności testowania jednostek.

Trzymaj swoją logikę biznesową poza warstwą interfejsu użytkownika, dzięki czemu możesz łatwo pisać dla nich testy, a będziesz dobry.

Polecam TestDriven.Net lub ReSharper ponieważ oba łatwo integrują się z wizualnym Studio.

Cóż, jeśli myślisz, że może się złamać, napisz do niego test. Zwykle nie testuję settera / gettera, ale lets mówi, że robisz go dla User.Name, które łączą imię i nazwisko, napisałbym test, więc gdyby ktoś zmienił kolejność na nazwisko i imię, przynajmniej wiedziałby, że zmienił coś, co było testowane.

Kanoniczna odpowiedź brzmi: "przetestuj wszystko, co może się złamać."Jeśli masz pewność, że właściwości nie ulegną uszkodzeniu, nie testuj ich.

A gdy coś się zepsuje (znajdziesz błąd), oczywiście oznacza to, że musisz to przetestować. Napisz test, aby odtworzyć błąd, obserwuj, jak się nie powiedzie, a następnie napraw błąd, a następnie obserwuj przebieg testu.

Zalecałbym napisanie wielu testów dla metod uwierzytelniania i zapisywania. Oprócz przypadku sukcesu (gdzie podane są wszystkie parametry, wszystko jest poprawnie napisane, itp.), dobrze jest mieć testy dla różnych przypadków awarii (nieprawidłowe lub brakujące parametry, niedostępne połączenia z bazą danych, jeśli dotyczy, itp.). Polecam pragmatyczne testy jednostkowe w C# z NUnit jako referencję.

Jak stwierdzili inni, testy jednostkowe dla getterów i seterów to przesada, chyba, że jest logika warunkowa w Twoich geterach i seterach.

Chociaż możliwe jest prawidłowe odgadnięcie, gdzie twój kod wymaga przetestowania, ogólnie uważam, że potrzebujesz metryk, aby potwierdzić to odgadnięcie. Testowanie jednostkowe moim zdaniem idzie w parze z metrykami pokrycia kodu.

Kod z dużą ilością testów, ale mały zasięg nie został dobrze przetestowany. To powiedziawszy, Kod ze 100% pokryciem, ale nie testowanie przypadków związanych i błędów, również nie jest świetny.

Chcesz mieć równowagę między wysokim pokryciem (minimum 90%) a zmiennymi danymi wejściowymi.

Remember test na "śmieci w"!

Ponadto test jednostkowy nie jest testem jednostkowym, chyba że sprawdza, czy nie doszło do awarii. Unit-testy, które nie mają twierdzeń lub są oznaczone znanymi wyjątkami, po prostu sprawdzą, czy kod nie umiera podczas uruchamiania!

Musisz zaprojektować testy tak, aby zawsze zgłaszały błędy lub nieoczekiwane/niechciane dane!

To czyni nasz kod lepszym... kropka!

Jedną z rzeczy, o których zapominamy podczas test driven development, jest cel naszych działań. Jeśli test jednostkowy jest zapisywany po wprowadzeniu kodu produkcyjnego, wartość testu spada (ale nie jest całkowicie utracona).

W prawdziwym duchu testów jednostkowych, testy te są Nie głównie po to, aby "przetestować" więcej naszego kodu; lub aby uzyskać 90% -100% lepsze pokrycie kodu. To wszystko korzyści fringe z napisania testów w pierwszej kolejności. Duża wypłata polega na tym, że nasz kod produkcyjny kończy się być napisany znacznie lepiej ze względu na naturalny proces TDD.

Aby pomóc lepiej przekazać ten pomysł, następujące mogą być pomocne w czytaniu:

Błędna teoria testów jednostkowych
celowe tworzenie oprogramowania

Jeśli czujemy, że akt pisania kolejnych testów jednostkowych pomaga nam uzyskać produkt wyższej jakości, to możemy być / align = "center" bgcolor = "# e0ffe0 " / cesarz chin / / align = center /