Zaczęłam trochę ćwiczyć testy jednostkowe. Napisałam sobie wczoraj grę - te słynne connect four. Dzisiaj zaczęłam klepać do tego testy jednostkowe. Mam prośbę do Mirków z #programowanie i z #java aby rzucili okiem i ewentualnie powiedzieli co robię źle/dobrze. Nie chciało mi się narazie całego projektu wrzucać, tylko jedną klasę Board. Jest to na tyle trywialny i autonomiczny kod, że chyba nikt nie będzie miał problemu z rozczytaniem. Klasa z Testem pod spodem.
1. Jest to Java, a nie jedynie słuszny język programowania jakim jest C# 2. Wywal metodę test() i dodaj atrybut @Test do metod getFieldTest i setFieldTest. Obecnie zrobiłaś tak jakby jeden podwójny unit test.
@ZasilaczKomputerowy: nie w kwestii testów, ale funkcja isEndOfGame() to niezły bolierplate... Uprość to trochę. Może zamiast tych niektórych statycznych finalnych zmiennych na górze zrób Enumy? Np. Player? Bo te psf'y straszą ( ͡°͜ʖ͡°)
- testy powinny być rozdzielone, tj. tworzysz 2 metody testowe, jedną dla column, jedną dla field, i obie oznaczasz jako @Test - metoda setColumn nie rzuca wyjątków, skąd zatem w testach bloki try-catch? - pętle i asercje w pętlach nie są dobrym pomysłem przy testach jednostkowych - ciężko się to debugguje - w tych testach ogólnie za dużo się dzieje, można je najprawdopodobniej rozbić na
shouldTestSetColumnMarkForPlayerA brzmi lepiej? Nie ma się co bać rozległych nazw.
To. Długie nazwy streszczające obiekt testu danej metody są świetną konwencją. Z jakiś powodów wszyscy z którymi robiłem jakiś projekt na studiach bali się jej stosować.
Gdzie? 1. W testach: a nie musi być? 2. W kodzie programu: wszystkie metody pblic są używane gdzieś na zewnątrz w innych klasach. Pola protected są protected bo być może klasa będzie rozszerzana.
metoda setColumn nie rzuca wyjątków, skąd zatem w testach bloki try-catch?
A gdzie w testach jest setColumn w try-catch?
pętle i asercje w pętlach nie są dobrym pomysłem przy testach jednostkowych
@ZasilaczKomputerowy: Wait, wait, getWidth() returnuje width? No ja mam nadzieję, że to będzie stestowane, ponadto używasz tego w innych testach a nie stestowałaś właśnie tego, co jeśli to nie działa? Wszystkie testy leżą. ( ͡°͜ʖ͡°)
Pytam o testy. Resztę to pisałam wczoraj po dwóch piwach, żeby mieć co testować, nie patrzeć na to bo nie ma to nic do rzeczy.
@ZasilaczKomputerowy: doceniam, że piszesz testy zanim podjęłaś pracę w zawodzie, niewielu programistów może się tym pochwalić. Ale z takim podejściem za daleko nie zajedziesz.
Nie da się dobrze przetestować tragicznie napisanego kodu. Do dobrych unit testów potrzebujesz SOLID, a drugie magiczne pojęcie to piramida testów. Fowler,
@ZasilaczKomputerowy: Wygeneruj sobie pokrycie kodu testami – znajdziesz fragmenty, które jeszcze nie masz przetestowane.
A tak w ogóle to TDD: pisz testy i kod jednocześnie. Nie dopisuj testów do już istniejącego kodu, bo jest duża szansa, że coś w testach pominiesz, będą nieadekwatne lub będą sprawdzały nie do końca to co „twórca miał na myśli”.
Tzn czasem trzeba dopisać testy do istniejącego kodu, ale chodzi mi, żebyś zainteresowała się dodatkowo TDD
@ZasilaczKomputerowy: Metody testujące, tak samo jak kod produkcyjny (testowany) powinny być krótkie i opisujące siebie. Generalnie (prawie) wszystkie reguły czystego kodu obowiązują także dla testów. Mniejszą uwagę przykładamy do duplikacji, bo testy mają stanowić „przykłady użycia”.
Lepiej więc trochę więcej duplikacji, ale za to ważne, żeby była jasna struktura testu – jak przygotowujesz klasę, jak ją używasz, co oczekujesz.
klik
1. Jest to Java, a nie jedynie słuszny język programowania jakim jest C#
2. Wywal metodę test() i dodaj atrybut @Test do metod getFieldTest i setFieldTest. Obecnie zrobiłaś tak jakby jeden podwójny unit test.
isEndOfGame()to niezły bolierplate... Uprość to trochę.Może zamiast tych niektórych statycznych finalnych zmiennych na górze zrób Enumy? Np.
Player? Bo te psf'y straszą ( ͡° ͜ʖ ͡°)@copychef:
1. spory o języki programowania pozostawiam studentom pierwszego roku
2. Dzięki, 1 dobra rada ;)
- czemu wszystko jest public/protected?
- testy powinny być rozdzielone, tj. tworzysz 2 metody testowe, jedną dla column, jedną dla field, i obie oznaczasz jako @Test
- metoda setColumn nie rzuca wyjątków, skąd zatem w testach bloki try-catch?
- pętle i asercje w pętlach nie są dobrym pomysłem przy testach jednostkowych - ciężko się to debugguje
- w tych testach ogólnie za dużo się dzieje, można je najprawdopodobniej rozbić na
Aczkolwiek refactoring kodu 'produkcyjnego' to temat na osobny, obszerny wpis :)
>pisane po dwóch piwach, żeby mieć co testować>javadocxD
To. Długie nazwy streszczające obiekt testu danej metody są świetną konwencją. Z jakiś powodów wszyscy z którymi robiłem jakiś projekt na studiach bali się jej stosować.
Komentarz usunięty przez autora
Gdzie?
1. W testach:
a nie musi być?
2. W kodzie programu:
wszystkie metody pblic są używane gdzieś na zewnątrz w innych klasach. Pola protected są protected bo być może klasa będzie rozszerzana.
A gdzie w testach jest setColumn w try-catch?
@ZasilaczKomputerowy: doceniam, że piszesz testy zanim podjęłaś pracę w zawodzie, niewielu programistów może się tym pochwalić. Ale z takim podejściem za daleko nie zajedziesz.
Nie da się dobrze przetestować tragicznie napisanego kodu. Do dobrych unit testów potrzebujesz SOLID, a drugie magiczne pojęcie to piramida testów. Fowler,
Np masz metodę
getField, która ma trzy ścieżki działania:1.
x >= WIDTH=> leci wyjątek2.
y >= HEIGHT=> leci wyjątek3.
x zwracana jest wartość
testGetFieldThrowsWhenXOutOfBoundsTym samym powinnaś mieć trzy metody testowe:
1.
2.
3.
BTW, co jak
lubybędą liczbami ujemnymi? Jeśli walidujesz czy wartość nie wykracza poza boarda, to-5` raczej też wykracza,A tak w ogóle to TDD: pisz testy i kod jednocześnie. Nie dopisuj testów do już istniejącego kodu, bo jest duża szansa, że coś w testach pominiesz, będą nieadekwatne lub będą sprawdzały nie do końca to co „twórca miał na myśli”.
Tzn czasem trzeba dopisać testy do istniejącego kodu, ale chodzi mi, żebyś zainteresowała się dodatkowo TDD
Lepiej więc trochę więcej duplikacji, ale za to ważne, żeby była jasna struktura testu – jak przygotowujesz klasę, jak ją używasz, co oczekujesz.