Jak i kiedy pisać testy?

0

Od jakiegoś czasu programuję w C#.
Coś tam umiem już napisać, lecz zupełnie nie ogarniam kiedy pisać testy (np. jednostkowe).

Czy mając taki prosty programik:
https://github.com/TomaszTop/Zamow

można by już jakiś test (oczywiście taki który ma sens, nie koniecznie jednostkowy, może jakiś inny się tu przyda...) napisać?

0

W teorii: Przed napisaniem kodu.

W praktyce jak najpóźniej albo wcale. Oceń czy to co robisz ma w sobie jakąś wartość? Jeśli ma wartość potraktuj test jako inwestycję. Jeśli pisanie testu dla konkretnej grupy modułów może uchronić Cię przed dużymi stratami wtedy nawet się nie pytaj, tylko rób to natychmiast.

0

No jasne, że można, jak jakaś publiczna metoda zwraca wartość to piszesz test, jak nie zwraca to możesz sprawdzić czy rzuca odpowiedni wyjątek, jak przekazujesz jakąś wartość w parametrze to czy dobrze działa np. jakiegoś stringa czy cuś.

0

@manuel.Artificer dasz radę pokazać to na jakimś przykładzie do tego kodu który wrzuciłem?

@nohtyp dlaczego jak najpóźniej albo wcale?

2

@nohtyp hahahahahaah dobre dobre bardzo dobre, a potem klient po drobnych zmianach wysyła ci informacje, ze pól systemu nie działa. nie wiem gdzie pracujesz ale polecam uciekać :D Tam gdzie ja pracuje jest z góry przewidziane połowa czasu na pisanie testu i co chwila ratują dupę. Jedyne z czym jest dylemat i odchyły to kiedy która praktykę stosować. Przyjęło sie, że lecimy na tdd ale w aktualnych projektach w każdym jednak najpierw piszemy ciało metody a potem testy do niej, to jest jednak prostsze. :)

0

A wiesz jak w Visualu utworzyć test jednostkowy? Jak nie to tu masz jakiś link (pierwszy z brzegu, nawet nie sprawdzałem ale skoro od MS to chyba jako tako wytłumaczone):

https://msdn.microsoft.com/pl-pl/library/ms182532.aspx

Tak patrzę na ten kod i powiem, że najpierw to powinieneś go poprawić, bo ciężko jakiś test napisać. Weźmy np. taki Database. W konstruktorze na sztywno podałeś mu nazwę pliku .db (bardzo źle). Jak już tworzysz taki obiekt to w konstruktorze przekazujesz ścieżkę do tej bazy, a nie na sztywno to wpisujesz. Potem coś się zmieni i biblioteka do przebudowania. No i za ogólnie przechwytujesz te wyjątki. Exception bym używał tylko w głównym kodzie programu, no i poza tym masz typ MyException i nie ma w tej nazwie żadnej podpowiedzi co to za wyjątek. Jak już tworzysz typ wyjątku to korzystaj ze snippeta. W Visual Studio jak wpiszesz Exception i klikniesz dwa razy TAB to doda Ci odpowiedni kod, którego aktualnie brakuje w tej klasie MyException. Snippety to naprawdę fajna sprawa, piszesz pętle, ify itp. chwila i już masz cały blok kodu. Ale wracając do tematu no to np. żeby przetestować jakąś metodę czy rzuca odpowiedni wyjątek to masz tego typu kod:

	[TestClass]
    public class MailTests
    {
        [TestMethod]
        [ExpectedException(typeof(MyException))]       
        public void SendMailTest()
        {
            Mail mail = new Mail("", "", "", "", true, 1);
            mail.SendMail("", "", "");
        }
    }
0

Coś tam umiem już napisać, lecz zupełnie nie ogarniam kiedy pisać testy (np. jednostkowe).

To zależy.

1 użytkowników online, w tym zalogowanych: 0, gości: 1