Az írás egy egyszerű kezelés, vizsgálat
Régebben azt gondoltam, hogy lehetetlen, hogy az 1C egység tesztelése (valójában nincs mindenütt objektumok, osztályok, és a szokásos. M.). Néha Infostarte speciális kezelést jelent meg, de gyakran több meggátolni tesztelése szálak, mint vonz. Aztán megtudtam xUnitFor1C. Kiderült, hogy a tesztelés 1C általában nem túl nehéz, még akkor is, összehasonlítva más nyelveken. Ebben a cikkben fogok mesélni az első tapasztalatok.
Szeretném megköszönni, hogy a cikk úgy küldetést. Ez szükséges volt, hogy álljon a tanulmány xUnitFor1C, a munka, amely a későbbiekben még kitérünk.
És így ugyanaz xUnitFor1C fejlesztők egy nagy sor eszközt.
xUnitFor1C e 1c egy sor külső kezelések, megkönnyítve, és ami a legfontosabb, szervezni tesztelés. Ebben a cikkben, csak xddTestRunner.epf (vypolnyatel teszt) kell használni.
Kifejlesztett egy kezelés során a robot napló és a kijelző kattintható jelentést. Egy további komplexitás a következtetést a jelentés jelző üzeneteket, amelyek során felmerült a robot (például során a dokumentumot). Alkalmazzuk a „teszt-vezérelt fejlesztés.”
Főzés környezetben.
A vizsgálatsorozat - a feldolgozás, az export funkció soderzhaschaa PoluchitspisokTestov (YunitTestirovanie). A dokumentáció egy sablont nyújt az ilyen kezelést. Hozunk létre, és mentse el. A feldolgozó egység a következő:
Fuss xddTestRunner.epf. interfész meglepően barátságos hozzám. Load tesztek a katalógusban. Ellenőrizze. Látnia kell egy tesztet. A vizsgálatot meg nem. Fix a tesztet.
Most, a teszt sikeresnek kell lennie.
fejlesztési ciklusban.
1) létrehozása törött teszt
Újraindítása vizsgálatok jegyzékét, ellenőrizzük tesztek már a 2. és a második sikertelen.
2) Ennek csak annyi, hogy teszt sikeres volt.
Soda táblázatos részt kezelési mezők „Run” és a „szöveg”.
Hozzátéve, hogy a modul
Ellenőrizze, hogy a teszt telt el.
3) újratervezés.
Ezzel a megközelítéssel, ha a kód alá tartozó teszteket és meg lehet változtatni, félelem nélkül, hogy a változások „eltünt következményekkel jár.”
Szerint TDD lépéseket 1,2,3 folyamatosan ismételve, és az iteráció időtartama legyen a lehető legkisebb.
tesztek függetlenségét.
Az alábbi eljárások függetlenségének biztosítása érdekében:
Szükség esetén ismételje meg.
Ha szükséges, ismételje meg újra ..
Teljesen írás folyamata is megtekinthető a kötelezettséget az adattár a GitHub
Én nem találtam, hogyan kell letölteni ingyenesen, így a tároló, és csatolni kell a cikk archív.
Köszönöm a figyelmet, remélem nem lesz ember, aki miután ezt a cikket el fogja fogadni a leírt elvek és a világ lesz egy jobb hely.
Ui Ki van itt?
Ha van egy kérdés, „hogyan lehet a kérelem”, „hogyan lehet egy nyomólemez”, a válasz ott van. A végén, akkor láthatjuk, hogy ez hogyan történik egy tipikus konfigurációban. De amikor nem volt kérdés: „Mit írjak a teszt? Mi a vizsgálati jelentéseket? Kezelhető formában? A rekord az adatbázisba?” tipikus konfigurációk, a válaszok nem találtam. Így kellett feltalálni mankója ..
De valaki már alkalmazzák ezeket a megközelítéseket (amikor valaki írta xddTestRunner). Talán ez a valaki szembe sok nehézség és megoldani azokat. Ezért, ha valaki meg akarja beszélni, egy újabb folyamat, amelyben nem minden olyan simán és szépen kiderült. Alig várom, hogy építő jellegű kritikát és a linkeket, hogy nézd meg. =)