[dbdbdbdb]

#programowanie

[tamian]

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

[pan_hrabia]

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

[laki1]

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

[tamian]

@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 ( ͡° ͜ʖ ͡°)

[pan_hrabia]

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

[maciejze]

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

[tamian]

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

[rbielawski]

Mózgu

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

[sasik520]

@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 i

[MacDada]

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

[MacDada]

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. o.O

Co do zjadania procesora i pamięci – żaden problem. Mamy szybkie

[MacDada]

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ż możliwe jest przekazanie Y'.

I tu programista ma decyzję

[MacDada]

EOT.

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

[sasik520]

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 #!$%@?