Bugfix es a unit test viszonya

Szoktak mondani, hogy ha javitassz egy bugot, arra irj unit testet is, hogy ne ismetlodhetsen meg ujra, legyen tesztelve onnantol fogva. TDD azt mondja, hogy elobb ird meg a tesztet, es csak utana a kodot. Szoval a bugfixre elobb a unit testet kell irni, igy ugye sokkal egyszerubb reprodukalni a hibat az adott kodreszletben, majd a kodban kell fixalni a bugot, mig a teszt at nem megy.

Ezt az egeszet idoben visszatekerve a legelso kodsorhoz, az elso TDD unit tested gyakorlatilag egy bugfix. Leirod hogy kellene a kododnak mukodnie, nem ugy mukodik, szoval fixalod.

Tehat a TDD a folyamatos bugfixalas metodologiaja.

Hozzászólások

A TDD inkább a kódban kifejezett specifikáció. A teszt specifikálja, hogyan kell a rendszernek működnie. És azért kódban specifikáljuk, mert így kiváló eszközeink vannak arra, hogy a specifikációt ellenőrizzék - maguk a számítógépek. Automatizálják azt a működést, amit nagyon sokan még mindig kézzel csinálnak.

És igen, a bugok egy része a papíralapú, nem formalizált specifikáció félreértéséből vagy hibás implementációjából adódik, így persze mondhatjuk, hogy a TDD az a bugfixekre van, pedig dehogy. A TDD az előírt logika formalizálására van.

Ezzel egyutt altalanos gyakorlatnak latom, hogy
- feature commit
- elromlik par unit test
- unit test atirasa
- push

Specifikacio atnezeserol sokszor szo nincs, hiszen maga a feature ugyfel nyomasra jon, es gyorsan, surgosen le kell szallitani. Nem egy ilyen esetet lattam. Bennem ilyenkor azert felmerul, van-e ertelme egyaltalan unit testelni. :)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Ne keverd a unit testet es a TDD-t. Meg ha nem is hasznalod a TDD-t, unit testelni meg utolag is van ertelme, ezzel garantalod ugyanis, hogy mas kulso behatasok nem fogjak a te kodod mukodeset megvaltoztatni, illetve dokumentalod is, hogy a kododnak hogyan kell mukodnie (ha ugy tetszik, peldat adsz a hasznalatara). Ha valaki mas kerul a te szekedbe, es meg akarja valtoztatni a kododat, akkor jo esellyel eltori az unit testet, igy mindenkeppen meg kell vizsgalnia, hogy mi volt azzal a koddal az eredeti szandek.
--
Blog | @hron84
Üzemeltető macik

Igy van, de nem akartam a tankonyvi leiras fele menni, most valami elkapott es ilyen "forditsuk ki" hetem van. Masreszt a bugfix az igazabol a specifikacio foltozasa. Hiszen ha bug van a kodban, akkor a specifikacio nem volt tokeletes, arra a scenariora nem gondolt senki, tehat ki kell egesziteni. Tehat ebbol kovetkezoen bugfixek halmaza == specifikacio, specifikacio == bugfixek halmaza.

"elso TDD unit tested gyakorlatilag egy bugfix"

szokták azt is mondani, hogy először írj tesztet, csak utána implementációt

Ez lehet, de rám mostanában mindég a maradék 2 eset szokott jutni ;-). Csak félig viccből mondom.

(Igaz, mostanában a tesztelést (sőt, verifikációt) próbálom a Scala DSL-ként megvalósított hardvertervező nyelven leírt hardverre ráhúzni, ami ebben a formában eléggé új dolog.

Avagy: teszteljünk hardvert szoftveres tesztkörnyezettel, egy viszonylag egzotikusnak nevezhető, még nem kiforrott DSL segítségével)

Olvastam a TDD-ről, de én magam sosem használtam (nem vagyok fejlesztő).

Az érdekelne, hogy ha nem back end részt ír valaki, ahol ugye teszt eseteket definiálni és automata teszteket írni, hanem front end készül, akkor lehet-e erre is TDD-t használni, és ha igen, hogyan definiálja a teszt eseteket az ember?

Mondjuk meg akarom írni azt, hogy valaki belép.
Írok egy tesztet, aminek az a vége, hogy sikeres volt a belépés.
De hogyan tesztelek? Valami GUI teszt automatizáló eszközzel (Sonar? Selenium? valami ilyesmi névre emlékszem) szimulálom a felhasználónév és jelszó mező kitöltését és a login gomb megnyomását, még mielőtt magát az ablakot és a mezőket meg a gombot egyáltalán létrehoztam?

Nezd meg a Cucumbert illetve a BDD egyeb agazatait is. Ez szepen betagolodik a TDD principle-be, a user story-t definialod elore, mint teszt eset, es ahogy megvan a frontend kod, moge tudod pakolni a tenyleges tesztet, ami mar lefut. Sajnos nem teljesen 100%-osan TDD, de a TDD lenyege a specifikacio, azt pedig a user story megteszi.

Ilyesmiket fogsz egyebkent irkalni storykent:


Gven I have an user with email "gee@geez.hu" and password "Huha456"
When I fill text fields with my username and password
And I click on button with label "Login"
Then I should get "You successfully logged in"
And I should see my name on the screen

--
Blog | @hron84
Üzemeltető macik