• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    KOJAProgramovani 40+
    ALMAD
    ALMAD --- ---
    DRUDRIGER2: Ja ti nevim, obcas zas plati “zadna otazka neni dost blba” #kecy

    DRUDRIGER2
    DRUDRIGER2 --- ---
    ja to delam tak ze mu v junie (inteliji v goland) napisu jasne udelej mi testy a popisu mu presne funckionality ktere chci aby k nim napsal testy. priste je vyjmenuji. udela mi jen ty testy ktere fakt potrebuji, a samozrejme to musim prohlidnout co tam dela, neco smaznout ci pozmenit.

    Jako sam sem to skouzel davno ze se napsal jen napis testy pro to co vidis v stage v gitu, ale to fakt generovalo strasne mec a nepotrebnych testu.

    jako chce to zlaotou cestu, neco napise on neco ja, a dulezite ji psat konkretne. na blbou otazku je blba odpoved... u AI to plati dvakrat
    VOY
    VOY --- ---
    AXTHEB: Minimalne do doby nez zpusobi nejaky incident ;-). Ale jako jo, kdyz pak zmenis tu vnitrni implementaci a testy porad prochazi, tak to je rozhodne dopaminovy high ;-).
    AXTHEB
    AXTHEB --- ---
    VOY: Jo, není to snadné.
    Pak ale zjistíš, že potřebuješ změnit interface té privátní metody a jen se kocháš všemi těmi testy, které není třeba opravit:)

    A taky víš co, pokud ten edge case neumíš vyvolat z venku, asi ho není třeba testovat:)
    VOY
    VOY --- ---
    AXTHEB: To mi prave prijde, ze je nelehka vec, pres nejakou volajici funkci je casto hodne pres ruku otestovat vsechny edge cases. Samozrejme asi neni nutne snazit se dosahnout 100% coverage, ale pokud pridam prostrednika tak se mi zda, ze uz se ani nebavime o unit testu, pak uz testuju jestli verejna funkce spravne vola nejakou privatni implementaci.
    AXTHEB
    AXTHEB --- ---
    VOY: přes tu funkci, která to volá. Samo, nejde to udělat bezhlavě.
    Jak jsem psal níž, nakonec stejně skočím u toho, že se mi unit testy přetaví na e2e. Ve skutečně unit testech pak optimálně zůstanou jen nějaké edge case a failure mode testy, u kterých by e2e setup nebyl snadný. Race conditions, třeba.
    VOY
    VOY --- ---
    AXTHEB: Myslis to ted tak, ze mas nejakou "privatni" funkci, ktera neni soucasti exportovaneho API a tyhle testy odmazes? Pokud tomu tak je, jak tu logiku otestujes? Pres nejaky E2E testy? Nebo pres tu funkci, ktera tu privatni vola?
    AXTHEB
    AXTHEB --- ---
    KOLCON: To ti z toho vychází dost implicitně, píšeš testy, které tě někam posunou. Já navíc dost často testy mažu, když mám unit testy na nějakou funkci a tu používám, tak jakmile je dopsané to místo, kde si funkci používám, tak to proberu, aby na tu vnitřní funkci bylo minimum testů (klidně žádné).
    SULTHAN
    SULTHAN --- ---
    VOY: test, co nic netestuje, je naprosto klasický v jakémkoliv unit-testování frontendu. Co taky testovat na frontendu? Že se někde něco zobrazí? Že se po kliknutí na tlačítko provede nějaká funkce? Prostě to vůbec nedává smysl a zpravidla se to posouvá na vyšší úroveň interakčních testů (proklikávání oproti mockům), E2E testů (proklikávání oproti reálnému prostředí), obojí spojeno se screenshotováním (reálně nic netestuje, ale diffy zajišťují, že se nic nerozbilo).
    TOOMIX
    TOOMIX --- ---
    Tak mě tak napadlo... jaká je dnes náhrada za kdysi skvělý .NET Remoting? Normální API?

    .NET Remoting - Wikipedia
    https://en.wikipedia.org/wiki/.NET_Remoting
    VOY
    VOY --- ---
    KOLCON: snadno se řekne, hůř zajistí že to všichni v týmu uvádí do praxe :-)
    KOLCON
    KOLCON --- ---
    AXTHEB: Jo ale taky to říká "netestujte každou kravinu ale otestujte to co to má dělat "
    AXTHEB
    AXTHEB --- ---
    KOLCON: Businesse logiku ti řídí spíš BDD, i když TDD (mi) většinou do BDD víceméně přeteče.
    Jinak tahle otázka v rámci TDD imho nemá úplně smysl. Základní návod je napsat co nejjednodušší failující test, který tě posune směrem k zadání, ten co nejjednodušším způsobem vyřešit, pak se pokusit to nějak zrefaktorovat a opakovat.
    Moje zkušenost je, že většinou píšu unit testy, které se s postupným vývojem aplikace transformují ve víceméně end to end testy.
    KOLCON
    KOLCON --- ---
    AXTHEB: Imho je největší problém v tom si tak nějak rozumně nastavit co vlastně tím testovat. Business logiku? Každou proceduru a všechny možné stavy a výjimky? Integrace? Něco jiného?
    VOY
    VOY --- ---
    AXTHEB: Ano, staci to a presto to drtiva vetsina lidi nedela. Mozna vetsina lidi neni tak organizovana. Mozna je to problem kdyz kolegove v tymu touhle metodikou nejedou. Mozna je to neprakticke z jinych duvodu. Ja se to tak snazim delat, ale zas bych nerekl, ze jsem v tomhle nejak extra religious, predpokladam, ze nejaky TDD purista by mi asi dokazal lecco vytknout. Samozrejme jsou problemy, co se k tomuhle stylu vyvoje propujcuji vic a min.
    SATAI
    SATAI --- ---
    AXTHEB: což neznamená, že to musí v dané situaci dávat smysl
    AXTHEB
    AXTHEB --- ---
    VOY: Nope. Stačí překonat ten vstupní pocit, že víš jak na to, nastudovat si to a pak (s výjimkou onoho vytváření testů k neotestovanému cizímu kódu) můžeš to kolečko red/green/refactor použít úplně kdykoliv.
    VOY
    VOY --- ---
    AXTHEB: To z nej dela skvelou metodiku do slonovinove veze :-)
    SULTHAN: Zminil jsem hlavne react, protoze tam byl jednu dobu popularni enzyme a pak i ta react testing library. A z toho mam porad trochu PTSD, videl sem moc testu co testovaly jestli se ve vyslednem stromu objevi veci, ktere predtim byly deklarativne specifikovany. Takovy test veru moc hodnoty neprinese. To cele doprovazene mockovanim ruznych globalnich zavislosti. Uf. Muselo to ven.
    SATAI
    SATAI --- ---
    AXTHEB: to platí o většině věcí ;-)

    Ale hlavně by se z toho neměla ideálně dělat ideologie, podle které je jiné psaní testů špatně
    AXTHEB
    AXTHEB --- ---
    VOY: Zásadní problém TDD je, že je hrozně těžké ho dělat - zejména proto, že spousta lidí si myslí, že ví jak na to (ale nedělá to), a když se o to pokusí, tak jim to nejde. Protože neví jak na to.
    Kliknutím sem můžete změnit nastavení reklam