Aktywne Wpisy
![](https://wykop.pl/cdn/c3397992/Konigstiger44_DxLbxaPQo0,q60.jpg)
marokoko 0
Od początku #wojna #ukraina z #rosja mówiło się z całkiem dużą dozą przekonania, że w wojnie napastniczej stosunek ofiar obrońców do atakujących wynosi spokojnie od 1:5 do 1:10. Czyli na jednego obrońcę ginie od 5 do 10 napastników.
Dane z Pentagonu (z połowy kwietnia 2023) oraz raport norweskiego szefa ministerstwa obrony, Erika Kristoffersena, jasno wskazują na to, że w tej wojnie na jedną ukraińską ofiarę przypada od 1.2 do 2 rosyjskich ofiar,
Dane z Pentagonu (z połowy kwietnia 2023) oraz raport norweskiego szefa ministerstwa obrony, Erika Kristoffersena, jasno wskazują na to, że w tej wojnie na jedną ukraińską ofiarę przypada od 1.2 do 2 rosyjskich ofiar,
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ć
>javadoc
xD
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.
testGetFieldThrowsWhenYOutOfBounds2.
testGetFieldReturnsFieldMarker3.
xBTW, co jak
lub
ybę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.