@lukasz1985m: co ma TDD/DI do optymalności systemu i "potworności"?
Jeśli chcesz testować "cały system", to w niektórych przypadkach wylądujesz z milionami możliwych kombinacji, których realne przetestowanie jest niemożliwe. A prędzej lub później się wydarzą.
10 metod, każda tworzy dwa rozgałęzienia w logicznym przebiegu programu. Żeby w pełni przetestwować program, masz możliwość utworzenia 2^10 lub 3* 10 + 1 testów (3 - na każdą metodę zakładam sprawdzenie, czy dobrze wywołujesz współpracownika
Idiotyzmem jest pisanie testów przed pisaniem właściwego kodu.
@lukasz1985m: Nie bierzesz pod uwagę, że jednym z głównych celów TDD nie jest tylko posiadanie testów – ale także praca nad dizajnem kodu. Pisząc „test”, a właściwie „specyfikację”, decydujesz jak będziesz chciał z tym kodem pracować, co od niego oczekujesz. I jednocześnie nie ma wtedy mowy, żeby jakiś fragment kodu był nieprzetestowany – nie dopisujesz implementacji, dopóki nie masz failującego testu.
Ma tyle, ze jak chcesz testować wszystko to musisz wypluwać tysiące fabryk albo nawalać kod przez refleksje(lub robi to za Ciebie framework), a wszystko w DI, gdzie każda klasa i każdy obiekcik utrzymuje wskaźnik do swojej zależności. Nie dość, że pochłania olbrzymie ilości czasu procesora to wygląda jak chlew i żry tony pamięci.
(tak, dobrze czytasz między wierszami: zmienne globalne lub statyczne (defacto jeden kij), które są tutaj jedyną alternatywą to p--------a normalność!)
Czy uważasz, że TDD jest sensownym sposobem prowadzenia projektów?
Komentarz usunięty przez autora Wpisu
Komentarz usunięty przez autora
Komentarz usunięty przez autora
@lukasz1985m: Po przyjrzeniu się jakości twoich wypowiedzi na mirko można odnieść zupełnie inne wrażenie
Jeśli chcesz testować "cały system", to w niektórych przypadkach wylądujesz z milionami możliwych kombinacji, których realne przetestowanie jest niemożliwe. A prędzej lub później się wydarzą.
10 metod, każda tworzy dwa rozgałęzienia w logicznym przebiegu programu. Żeby w pełni przetestwować program, masz możliwość utworzenia 2^10 lub 3* 10 + 1 testów (3 - na każdą metodę zakładam sprawdzenie, czy dobrze wywołujesz współpracownika
@lukasz1985m: Nie bierzesz pod uwagę, że jednym z głównych celów TDD nie jest tylko posiadanie testów – ale także praca nad dizajnem kodu. Pisząc „test”, a właściwie „specyfikację”, decydujesz jak będziesz chciał z tym kodem pracować, co od niego oczekujesz. I jednocześnie nie ma wtedy mowy, żeby jakiś fragment kodu był nieprzetestowany – nie dopisujesz implementacji, dopóki nie masz failującego testu.
Co w tym
Komentarz usunięty przez autora
@lukasz1985m: Po pierwsze, czy piszesz testy czy nie, zasady czystego kodu obowiązują (powinny obowiązywać).
Ty nie masz tutaj zarzutu do TDD, bo z TDD też można pisać wujowy kod. Ty masz zarzut, że ktoś w ogóle używa OOP, stosuje przy tym SOLID, itd.
Komentarz usunięty przez autora
@lukasz1985m: Myślę, że koledze @sasik520 nie chodziło o każdy możliwy sposób odpalenia funkcji, ale o każdy możliwy sposób zadziałania funkcji.
Tzn masz rację, że testuje się pod kątem scenariuszy – potrzebuję zrobić
X, więc przekazujęYi dostajęZ. Ale też@lukasz1985m: Jak na wszystkie argumenty odpowiadasz
XDi inwektywami to się zgadzam, że EOT.@
Komentarz usunięty przez autora