Hogyan kell helyesen kiválasztani az egységet a tesztcsomag túlcsordulásához orosz nyelven?
Rendes hétköznap volt, elkezdtem írni egy másik szokásos tesztet, de a teszt címének megírásakor valami baj van:
Körülbelül a közepén kezdtem felismerni, hogy valami rosszul megy, de nem álltam meg, és végül a teszt nevét adtam hozzá. A munkatársak nem értékelték a teszt hosszú nevét, de tetszenek nekem. Most, mint a testCorrectChangeCustomerRedirectUrl, használják. és a teszten belül elrejtett tesztek részleteit.
Nem értem ezt a lvlapot, vagy este fáradt vagyok.
Kérdés: Milyen kritériumok a jó tesztnév kiválasztásához?
UPD: Kérjük, nevezze meg a teszteket a projektjeiről.
Ismét a kolostorok futottak. Uraim, hát, tegyük fel a fejét. Ha a kérdés csak akkor érthetetlennek tűnik számodra, mert nem vagy a téma, akkor ez nem jelenti azt, hogy ez egy haszontalan kérdés. Ráadásul, ahogy már írtam, a programozásnak számos olyan területe van, amelyekben alapvetően lehetetlen egyértelmű választ adni, de ezek fontos területek. A legnyilvánvalóbb példa a szoftvertervezés. - andreycha december 15-én, 17: 13-kor
A tesztek nevét nem szabad gyönyörűnek választani. A nevet funkcionálisnak és a lehető legrövidebbnek kell választani - úgy, hogy a minimális számú szimbólum alapján világos, hogy milyen körülmények között és milyen körülmények között tesztel, valamint azért, hogy meg lehessen különböztetni egy adott tesztet több ezer embertől.
A gyakori elnevezési minták:
- TestClass_TestMethod_ConditionAndExpectedResult (egység tesztek esetén)
- TestMethod_Condition_ExpectedResult (egységek tesztjeihez)
- ConditionAndExpectedResult (olyan integrációs tesztek esetében, amelyek a funkcionalitás egész blokkját tesztelik egy bemeneti ponton keresztül)
Ebben az esetben, ha van egy állapot / ExpectedResult alkatrészek túl sok különböző kifejezések / találatok szerint csoportosítva „I”, akkor meg kell, hogy vizsgálja felül sem a fő cél a teszt (teszteli), illetve a legfontosabb feltétel, amely megkülönbözteti a teszt a többi, és a szakítás több különálló teszt esetében.
Mindenekelőtt azért küzdök, mert a névnek tájékoztatónak, de ugyanakkor a lehető legrövidebbnek kell lennie. Itt, mint a kód többi részével - annál kevesebb kóddal, annál kevesebb időt kell megértenünk, annál könnyebben foglalkozik vele. A neved alapján ez nem egy egyszerű kis egység teszt, hanem valami több, így nem lehet nagyon rövid név nélkül. Abban az esetben, ha már rendelkezik az Ügyfél teszt-osztályával. Azt korlátozni a név SelectLastTransactionProcess_CreateRecurringProfile_RedirectUrlShouldContainConfirmation. A címében sok szó ismétlődik: tranzakció, URL, ismétlődő profil stb. Elbocsátanak.
Egyensúlyt kell találni a név hossza és tájékoztató jellege között. Elég, hogy a nevek érthetõek legyenek a projektben lévõ fejlesztõknek, akik már rendelkeznek a szövegkörnyezettel és képesek megérteni, hogy mi a teszt. És ha ehhez meg kell adnod a cím hossza nem 30 karaktert, de 40-et, csináld. De nem kell törekedned annak biztosítására, hogy a nevek világosak legyenek mindenkinek, akikkel találkozol, az egész rendszerről beszélve, mivel ez olyan nehézségeket okozhat, amelyekkel nehéz megérteni a kilométereket. Nézd meg a szokásos kódodat, nézd meg a módszer nevét. Nem írja le a módszer nevében minden részletet, minden sort? Leírsz valami fontosat, a többi pedig rejtve van. Ugyanúgy a vizsgálati módszerekkel.
Tudja-e valaki, hogy mit kell tennie az integrációs tesztek nevével?> Hol vannak 100500 különböző feltétel?
Például a számlázás 5-10 féle árlistát eredményez, és a kombinációktól és a paramétereik kombinációitól függően (szintén kb. 5-10) különböző kimeneti mennyiségeket kell kiadnia. A számlázásra küldött konténer elveszi
30 sor. Ha a stílus a poszt úgynevezett teszt ez lesz testPayoutDebtorToGateOntopGateTransactionAmountGateToCreditorFlatPayinDebtorTo GateOntopTotalTransactionAmountGateToCreditorOntopTransactionAmount. és nem a teljes kontextusban.
Szükség van a teljes összegének kiszámításához az a feltételezés, hogy a árlisták lehet beállítani az alábbiak szerint: a bizottság típusát árlista típusú alapügylet - belső / összesen 0,1% + Bizottság 0.5rub cverhu, ólom forgalom kiszámítását. A második jutaléklista ontop / gate. még ugyanebben a stílusban csak 10, és egy pár implicit függőségek árlisták egymástól.
Azt mondanám, hogy paraméteres tesztre van szükség. Ez egy olyan teszt, amely különböző adatkészleteket tesztel azonos kóddal. Például az xUnit teszt keretrendszerben a Calculator.Add () módszer paraméteres tesztje így fog kinézni:
Parametrikus teszt nem kell felsorolni az összes körülmények neve - a neve tartalmazza csak egy teszt anyag, amelyet tesztelnek, egy adott ügyben. Az ön esetében ez olyasmi, mint RaschetItogovoyStoimosti_PoOsnovnoyIDopolnitelnoySdelke (angol fordítás magad, akkor törölje a területen). És a tesztelési módja így nézhet ki (míg az xUnit tesztadatok helyettesíthetők az ingatlanról és még egy különálló objektumról is):
Úgy gondolom, hogy számos tesztkörnyezetben paraméteres teszteket lehet létrehozni. A paraméterek beállításának módja eltérhet, de a lényeg ugyanaz marad: az adatok átkerülnek a szekcióba az adatokkal, a vizsgálat nevében csak a név neve szerepel.
A parametrikus tesztekkel kapcsolatos további információk a Sergei Teplyakov blogjában találhatók.
Az első "moduláris teszt"
Meg kell egyeznie önmagával vagy a csapattal arról, hogy mi a "moduláris teszt"?
Például Roy könyvében (lásd az "Ajánlott irodalom" című fejezetet) az "egység" egyértelmű meghatározása és a programozó számára nagyon kényelmes.
Anélkül, hogy világos és magabiztos megértése, hogy mi "egység" írni egység tesztek erősen nem ajánlom. Még akkor is, ha megértetted, hogy egy egység teszt más-más, mint amit Roy mond, egyébként egységesnek és stabilnak kell lennie Önnek vagy csapatának. Amelyhez valamilyen megállapodás szükséges.
A Roy "Unit Test" megértése:
Roy véleményem szerint a legmegfelelőbb és legmegfelelőbb elnevezési rendszert kínálja:
Ahol: a munkaegység az, amit az "egység" megért, vagy amit a csoporttal egyetértett. a forgatókönyv egy konkrét intézkedés a vizsgált objektum várható-eredmény-vagy-viselkedésére - ez a várakozás, hogy mi fog történni
Nyilvánvaló, hogy a json-dokumentum parserét érvénytelen fájlkiterjesztésű fájlban ellenőriztük, ezért az InvalidLogFileException-t dobni kell.
Látható, hogy ha a bytecode optimalizálva van, -1 visszaküldésre kerül, ha ismeretlen utasítás keletkezik
Komplex körülmények között írási egységvizsgálatok
- Ez teljesen más kérdés
- Ha röviden, egy moduláris tesztben egy ellenőrizni. Ha az állapot nehéz, akkor a feltételek mellett több is van, és több ellenőrzést - egységvizsgálatot kell végrehajtania
- Minden tesztben nincs feltételes logika. Ha a gyártási kódban két ág van, akkor az egyik if-rész, egy másik rész. Ez azt jelenti, hogy két egységet tesztel.
és így tovább. és hasonlók. De mindez egy másik vita témája
Mi a baj, véleményem szerint, a tesztedben:
Nagyon ajánlom letölteni, és jobb, ha megvásárolja a Art Of Unit Testing könyvet. Még ha hirtelen nem írnak C # -re. A tudás hasznos!
A teszt nagyon hosszú neve diagnózisnak tekinthető. Az ilyen jeleket különböző szempontokból lehet megtekinteni, de minden esetben, általában, jelzik a probléma jelenlétét vagy esetleges előfordulását. Minimális lehetőségek:
- A tesztelt kód a rossz architektúrát valósítja meg
- Ez nem moduláris, hanem esetleg integrációs teszt
- A tényleges tesztmodul helytelen végrehajtása
- A fejlesztő nem kapott elég alvást, és (vagy) a tudat transzformátorait felesleges mennyiségben használta
Mivel példát adtál, nézzük meg. Először megpróbálom kivonni a teszt angol nyelvéből az orosz jelentést:
"Győződjön meg róla, hogy az utolsó tranzakció feldolgozása után az ügyfélnek átirányított URL-címnek tartalmaznia kell az oldal visszaadási profiljának megfelelő URL-t, ha a tranzakció típusa végrehajtja a visszatérési profilt."
Tegyük fel, hogy az ilyen teszt teste kinézhet:
Az első megközelítésben minden úgy tűnik, hogy rövid, aranyos és olvasható. Tételezzük fel, hogy a teszt hogyan néz ki, ami az ellenkezőjét bizonyítja:
Természetesen azt feltételezzük, hogy a teszt előtt minden előkészítő munka a tényleges tesztekből származik:
Hogyan nevezhetem el a teszteket? Körülbelül annyira (a munkatervből):
A tesztosztály neve a kódolt osztály nevére utal. A vizsgálati módszerek neve pedig a vizsgált módszerek nevét jelöli a vizsgálati osztályban, és megpróbálja röviden beszámolni az egyes módszerekkel kapcsolatos vizsgálati feltételekről.
A szabályok elnevezése valamilyen módon Tao vagy Kung Fu. Meg kell figyelni az egyensúlyt. Ha a vizsgálati módszer neve hosszabb, mint a vizsgálati módszer kódja, akkor a fejlesztő, aki újratervezi a módszert, könnyebben és gyorsabban olvashatja és értelmezheti a kódot, mint az angol nyelvű irodalmi fordulatszámon.
A válasz a december 18-15-én 4: 21-kor készült
1. A tesztneveknek stringeknek kell lenniük
El kell kezdened azzal, hogy a teszt neve a függvény neve. A funkcióktól eltérően, nem hívunk teszteket kódból, a tesztnév csak a tesztek leírásához szükséges, így ez a leírás a tesztnaplóba kerül.
Ezért bizonyos tesztkörökben a tesztek nevei rendes sorok.
Például a Catch (C ++)
Vagy Mocha (JS és egyéb * szkript)
Érdekes kivétel olyan nyelvek, ahol az azonosítóknak lehetnek karakterei, például az F #
2. Ne ismételje meg magát (DRY elvét)
Ha a tesztkörnyezet lehetővé teszi a tesztek csoportosítását, akkor ezt fel kell használni. Ahelyett, hogy tesztelne valamit, amikor ez a jelenség. Something_Whenother_VotEth and Something_Whenother_otherNoThis tesztek csoportosíthatók.
Példa a Mocha / JS:
Továbbá gyakran nincs értelme megismételni a tesztkódot a teszt címében. Szükséges leírni, hogy mit teszt a teszt, és nem hogyan csinálja. Ezért a StartButton_WhenPressed_BecomesDisabled helyett írhat
Jellemzően a vizsgálat magában foglalja a kezdeti feltételeket (GIVEN / WHEN rész) és az eredményeket (THEN rész). Ha csak néhány tesztre van szükség néhány kezdeti körülmény esetén, akkor miért kell írni a címben, amit a THEN részben ellenőrzünk? Ez nyilvánvaló a kódból, és ha a teszt sikertelen, a sikertelen teszt szövegét a naplóba írja.
Minta teszt nevek
A tesztek nevei a tesztkerettől és a tesztszinttől (egység / integráció / regresszió) függenek.
Regressziós tesztek a Mocha / JS
A Catch / C ++ egység tesztjei, amikor a Catch a megosztott /
Újabb Catch / C ++ tesztek, címkékkel
A gtest / C ++ tesztek (a króm kódból)
A Golang tesztjei
Ha a tesztnév nem adható meg karakterlánccal, a CamelCase és az aláhúzás egyidejű használata meglehetősen jó olvashatóságot eredményez. Például, a TEST_CASE ("egy egység") helyett
Az elnevezési saját verziója nagyon hasonlít a több évszázaddal ezelőtt használt díszes módon, hogy neveket adjon a könyveknek, amikor a cím szinte az egész kötetet ábrázolja. Például a Robinson Crusoe teljes neve félelmetes-hosszúnak tűnik:
„Az élet, különleges és meglepő kalandok Robinson Crusoe, egy matróz York, aki élt 28 év magány egy lakatlan sziget partjainál of America, közel a száját az Orinoco folyó, ahol ő dobott hajóroncs, amelynek során a legénység kivéve őt meghalt, aki azt kalózok váratlan felszabadítása, amit maga írt "
a válasz december 15-én 15: 15-kor
@ Onedev.Link a perfekcionizmus a legrosszabb megnyilvánulásában vesz részt. Mászni a meghatározására irányuló vizsgálatok hiba előbb-utóbb, és valami egyenesen olyan szörnyű az, hogy nem (a végén, akkor nagy valószínűséggel nem írok a tökéletes, amely az összes vizsgált egyszerre), és akkor lehet elavult, és a módszer neve. Még ha így alapvetően teszteljék a logika leírás a saját nevében (kérdéses szükségesség), és így a neve megszerzésének irtózatosan hosszú, akkor érdemes feldarabolni a vizsgálati osztály pár újakat, amelyek mindegyike fogják tesztelni valami konkrétabb - DreamChild December 18-án, 9: 43-kor
Úgy vélem, hogy az egység tesztjének neve legyen tág. Különösen, ha a teszt BDD stílusban van írva. Különösen, ha a tesztelési keretek tudják, hogyan lehet olvasható jelentéseket készíteni.
Véleményem szerint tágas nevek (példák):
- testShouldAlwaysPreparePathsAndConvertThemInToArray
- testShouldRegisterNamespacesForMultipleDirectories
- testShouldThrowExceptionIfDbIsMissingOrInvalid
- testShouldSetOptionsWhenConfigPassedToTheConstructor
A tesztelés minden tisztességes kereteinél az ilyen módszernevek ilyen módon átalakultak (például):