Díky moc za video. Používání trait v kódu je hodně důležité, pokud člověk chce mít možnost testovat kód. Bez traity si asi těžko jen tak namockuji závislosti.
Месяц назад+1
No, jak kdy :) Někdy se to na mockování může hodit, ale přijde mi, že nadužívání traitů (obzvláště v podobě generik) čistě z důvodu jednoduššího testování je často spíše ke škodě, než k užitku. Netriviálně to může zkomplikovat kód, a vede to k tomu, že testy mockují závislosti, a pak se testuje něco jiného, než ve skutečnosti běží na produkci. Poslední dobou osobně preferuju spíše psát co nejvíce end-to-end testy, a spíše mockovat externí služby (tj. reálně v testu udělat DB, udělat TCP/IP port, se kterým kód komunikuje apod., radši, než tyto věci mockovat v paměti). Jinak ještě jednodušší věc, jak mockovat drobné věci bez použití traitů, je udělat si dvě verze struktury/funkce, která se v kódu používá. Jednu s #[cfg(test)] a druhou s #[cfg(not(test))], a pak to v podstatě funguje jako traity, akorát se tím nemusí zabordelařit půlka codebase.
Díky moc za odpověď a radu. J, někdy je jednodušší dělat end-to-end testy. Hlavně, když dneska není problém např. přes kubernetes, helm a gitlab pipline si nechat vytvořit neomezené množství prostředí. Např. pro každý merge request se dá udělat samostatné testovací prostředí. V praxi jsem narazil i na projekt, kde end-to-end testy jsou hodně drahé, kvůli velikost a komplexnosti projektu, databáze nebo dalších služeb. Kde potom end-to-end testy trvají hodiny namísto unit testů, které trvají max. desítky minut. Potom si myslím, že je lepší mít asi o něco složitější kód a testovat třeba počet zavolání metody nebo předávané parametry u namockované struktury.
Месяц назад+2
@@filiptomek3543 Jasně, všechno má své trade-offy :) Umění je v tom poznat, kdy který přístup použít.
Díky moc za video. Používání trait v kódu je hodně důležité, pokud člověk chce mít možnost testovat kód. Bez traity si asi těžko jen tak namockuji závislosti.
No, jak kdy :) Někdy se to na mockování může hodit, ale přijde mi, že nadužívání traitů (obzvláště v podobě generik) čistě z důvodu jednoduššího testování je často spíše ke škodě, než k užitku. Netriviálně to může zkomplikovat kód, a vede to k tomu, že testy mockují závislosti, a pak se testuje něco jiného, než ve skutečnosti běží na produkci. Poslední dobou osobně preferuju spíše psát co nejvíce end-to-end testy, a spíše mockovat externí služby (tj. reálně v testu udělat DB, udělat TCP/IP port, se kterým kód komunikuje apod., radši, než tyto věci mockovat v paměti).
Jinak ještě jednodušší věc, jak mockovat drobné věci bez použití traitů, je udělat si dvě verze struktury/funkce, která se v kódu používá. Jednu s #[cfg(test)] a druhou s #[cfg(not(test))], a pak to v podstatě funguje jako traity, akorát se tím nemusí zabordelařit půlka codebase.
Díky moc za odpověď a radu.
J, někdy je jednodušší dělat end-to-end testy. Hlavně, když dneska není problém např. přes kubernetes, helm a gitlab pipline si nechat vytvořit neomezené množství prostředí. Např. pro každý merge request se dá udělat samostatné testovací prostředí.
V praxi jsem narazil i na projekt, kde end-to-end testy jsou hodně drahé, kvůli velikost a komplexnosti projektu, databáze nebo dalších služeb. Kde potom end-to-end testy trvají hodiny namísto unit testů, které trvají max. desítky minut.
Potom si myslím, že je lepší mít asi o něco složitější kód a testovat třeba počet zavolání metody nebo předávané parametry u namockované struktury.
@@filiptomek3543 Jasně, všechno má své trade-offy :) Umění je v tom poznat, kdy který přístup použít.