- Hevi blogja
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"elso TDD unit tested gyakorlatilag egy bugfix"
szokták azt is mondani, hogy először írj tesztet, csak utána implementációt
- A hozzászóláshoz be kell jelentkezni
Először írd meg a teszt tesztjét, utána a tesztet.
- A hozzászóláshoz be kell jelentkezni
ilyenkor nem tudom, hogy komolyan gondolod, vagy viccelsz?
- A hozzászóláshoz be kell jelentkezni
Igazából én se. Csak azt tapasztaltam az elmúlt időben, hogy az összeadásnál kicsivel bonyolultabb kódrészek tesztelése már tud olyan bonyolult lenni, hogy felmerül a "ki a rendőr rendőre" kérdés.
- A hozzászóláshoz be kell jelentkezni
nem kétlem, hogy van ilyen, de 100 átlagos esetből 98-ban lehetne tesztírással kezdeni a fejlesztést (létező, átgondolt (valid) specifikációt feltételezve persze) - mégsem teszik meg azok, akik magukat "programozónak", meg "fejlesztőnek" nevezik
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
köszi, megnézem.
- A hozzászóláshoz be kell jelentkezni