@dbdbdbdb: Czy ktoś, kto zagłosował na "Nie" mógłby uargumentować swoje stanowisko? To ważne.

@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ółpracownikaPokaż całość

Nie dość, że pochłania olbrzymie ilości czasu procesora to wygląda jak chlew i żry tony pamięci.

@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.Pokaż całość

EOT.

@lukasz1985m: Jak na wszystkie argumenty odpowiadasz XD i inwektywami to się zgadzam, że EOT.

@lukasz1985m: ok, jeśli jesteś programistą, to prawdopodobnie znasz jakieś podstawy logiki. Może mógłbyś więc uargumentować swoje wypowiedzi?

Np. ja wykazałem, trywialnym, jak to nazwałeś, przykładem, że istnieją przypadki, dla których twoje podejście jest złe, lub raczej: problematyczne. Prawdę powiedziawszy nie widzę, dlaczego miałoby to nie działać w bardziej skomplikowanych przypadkach.

Po drugie, na co dzień pracuję przy aplikacjach, które alokują kilka GB pamięci - ze względu na rozmiary danych wejściowych. Dane dlaPokaż całość

@laki1: tddma kilka duzych plusow. Dla mnie jednym z wazniejszych jest pozniejsza latwosc w refaktoryzacji i utrzymaniu tak prowadzonego kodu.

Mózgu

@lukasz1985m: Po przyjrzeniu się jakości twoich wypowiedzi na mirko można odnieść zupełnie inne wrażenie

Cały system testuje się pod kątem scenariuszy lub przypadków użycia, a nie pod kątem każdej możliwej drogi wykonania

@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ę Y i dostaję Z. Ale teżPokaż całość

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ść!)

@Pokaż całość

@lukasz1985m: a nie czujesz tego, że jeśli twój tok rozumowania wywala się na trywialnym przykładzie, to tym bardziej będzie się wywalał na bardziej złożonym?

Ciekawy wynik. Zakladalem odwrotne proporcje: 30% na nie, 70 na tak.

@tamian: A czy ktoś głosująy na tak, mógłby uargumentować? ( ͡° ͜ʖ ͡°)

@laki1: Jednak więcej jest głosów na nie, i dlatego mi na tym zależy. Chcę tylko poznać opinię większości na ten temat ( ͡° ͜ʖ ͡°)

@lukasz1985m: Dobra ale jak czasem sprawdzisz czy coś w ogóle działa jak nie napiszesz testów?

@lukasz1985m: Rozumiem. Jakiego rozwiązania ty używasz, bądź jakie preferujesz?

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.

Co w tymPokaż całość