Czy używasz TDD? oraz pytania do TDD.

2
Seken napisał(a):

To jak stosowac TDD kiedy piszemy cos od nowa albo sami zostalo juz dobrze wyjasnione przez @Riddle. Ciekawi mnie co jesli pracujemy w dojrzalym projekcie i musimy dopisac nowy endpoint albo co gorsza zmodyfikowac jakis feature?

To, że w projekcie wcześniej nie było testów nie ma znaczenia, zawsze można zacząć je wprowadzać przy okazji nowych ficzerów.

0
scibi_92 napisał(a):

Jak implementacja bierze dane z d.. zamiast z parametrów to trudniej napisać test jednostkowy. Przykład w Javie to sławne new Date() Czy teraz po nowemu LocalDateTime.now()

Bierzesz i robisz TimeProvider i YOLO.

Ale wtedy TimeProvider też jest z parametrów, żeby moc podmienić implementacje dla testów :p

0
NeutrinoSpinZero napisał(a):

żeby metody zawsze zwracały wartość, nigdy void.

Nie rozumiem dlaczego metody powinny zawsze cos zwracac. Przyklad z aplikacji ktora pisze. Mam Klase Fish, jest to rybka ktora plywa sobie w stawie. Oraz metode spoil_energy ktora zmienia jej atrybut energy ponieważ rybka żyjąc traci energię. Ta metoda nic nie zwraca, według ciebie powinna ona zwracać nowy obiekt Fish ze zmienioną wartością energy?

6
Suchy702 napisał(a):

Ta metoda nic nie zwraca, według ciebie powinna ona zwracać nowy obiekt Fish ze zmienioną wartością energy?

Dokładnie tak by było w idealnym, czysto funkcyjnym świecie

0
Suchy702 napisał(a):
NeutrinoSpinZero napisał(a):

żeby metody zawsze zwracały wartość, nigdy void.

Nie rozumiem dlaczego metody powinny zawsze cos zwracac. Przyklad z aplikacji ktora pisze. Mam Klase Fish, jest to rybka ktora plywa sobie w stawie. Oraz metode spoil_energy ktora zmienia jej atrybut energy ponieważ rybka żyjąc traci energię. Ta metoda nic nie zwraca, według ciebie powinna ona zwracać nowy obiekt Fish ze zmienioną wartością energy?

W obiektowym świecie możesz mieć metodę Fish.swim(): void. To by znaczyło że ona:

  1. Albo nic nie robi (co nie ma sensu :D)
  2. Albo zmienia stan ryby
  3. Albo nie zmiania stanu (obiekt jest immutable), tylko robi coś poza programem, np zapisuje plik, wysyła maila, robi request, robi sleep()a, etc.

Jak mówi @KamilAdam, w funkcyjnym świecie punkt 2. nie może być.
Okej, w funkcyjnym jednak nie może być funkcji która zwraca void.

1
KamilAdam napisał(a):
Suchy702 napisał(a):

Ta metoda nic nie zwraca, według ciebie powinna ona zwracać nowy obiekt Fish ze zmienioną wartością energy?

Dokładnie tak by było w idealnym, czysto funkcyjnym świecie

Nawet poza czysto funkcyjnym światem ta nowa rybka jest o wiele lepsza niż void. Void to straszna kupa mszcząca się na refaktoringach.

1
Riddle napisał(a):
Suchy702 napisał(a):
NeutrinoSpinZero napisał(a):

żeby metody zawsze zwracały wartość, nigdy void.

Nie rozumiem dlaczego metody powinny zawsze cos zwracac. Przyklad z aplikacji ktora pisze. Mam Klase Fish, jest to rybka ktora plywa sobie w stawie. Oraz metode spoil_energy ktora zmienia jej atrybut energy ponieważ rybka żyjąc traci energię. Ta metoda nic nie zwraca, według ciebie powinna ona zwracać nowy obiekt Fish ze zmienioną wartością energy?

W obiektowym świecie możesz mieć metodę Fish.swim(): void. To by znaczyło że ona:

  1. Albo nic nie robi (co nie ma sensu :D)
  2. Albo zmienia stan ryby
  3. Albo nie zmiania stanu (obiekt jest immutable), tylko robi coś poza programem, np zapisuje plik, wysyła maila, robi request, robi sleep()a, etc.

Jak mówi @KamilAdam, w funkcyjnym świecie punkt 2. nie może być.

W obiektowym swiecie punkt 2 tez jest slaby. Problem polega na tym, ze OOP w takiej np. javie to jest straszna patologia i najwiekszy syf, ktory niestety zostal skojarzony jako wzorzec obiektowosci.

0
Seken napisał(a):

W obiektowym swiecie punkt 2 tez jest slaby. Problem polega na tym, ze OOP w takiej np. javie to jest straszna patologia i najwiekszy syf, ktory niestety zostal skojarzony jako wzorzec obiektowosci.

Czyli ponieważ ktoś tworzy shit w javie, to znaczy że w obiektówce nie może być mutowalnych obiektów?

Słaby argument.

1

@Riddle:
Druga czesc mojej wypowiedzi to byla taka bardziej dygresja. Moim skromnym zdaniem mutowalnosci powinno sie unikac w wiekszosci przypadkow (to nie znaczy, ze nigdy nie stosowac!). Generuje to spaghetti, dziwne sporadic bugi itd. Dlaczego Twoim zdaniem rozwiazanie @jarekr000000 odnosnie zwrocenia nowej ryby jest gorsze? Juz nawet na etapie testow widac, ze Twoje rozwiazanie ze zmiana stanu jest ciezsze do przetestowania.

0
Seken napisał(a):

@Riddle:
Druga czesc mojej wypowiedzi to byla taka bardziej dygresja. Moim skromnym zdaniem mutowalnosci powinno sie unikac w wiekszosci przypadkow (to nie znaczy, ze nigdy nie stosowac!).

No, zgadzam się.

Generuje to spaghetti, dziwne sporadic bugi itd. Dlaczego Twoim zdaniem rozwiazanie @jarekr000000 odnosnie zwrocenia nowej ryby jest gorsze? Juz nawet na etapie testow widac, ze Twoje rozwiazanie ze zmiana stanu jest ciezsze do przetestowania.

Zależy gdzie. Są miejsca w którym praca ze stanem jest bardziej sensowna niż nie. Np w GUI, setVisible(true),setVisible(false) jest dużo lepszym rozwiązaniem niż .getVisible()/getHidden() który zwraca nowy komponent.

Także to zależy. W logice, w corze, w domenie biznesowej, jak najbardziej stan jest ultimate złem. Ale nie wszędzie. W bazach danych, w gamedev'ie, w GUI właśnie.

To nie jest takie czarno białe. Na tak wysokim poziomie abstrakcji cięzko znaleźć "złotą zasadę" która zawsze działa.

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