ugrás a tartalomhoz

Test Driven Development – How Stupidity Spreads

Hidvégi Gábor · 2012. Okt. 8. (H), 16.43
Nem muszáj gondolkodás nélkül követni a divatot
 ■
1

Pár szóban össze tudnád

eddig bírtam szó nélkül · 2012. Okt. 8. (H), 20.41
Pár szóban össze tudnád foglalni a poszt lényegét?
(részben meghaladja az angolomat, részben... hát remélem, hogy csak szemüveget kellene csináltatnom :-( )
2

Nagyon sok helyen nem

Hidvégi Gábor · 2012. Okt. 8. (H), 21.19
Nagyon sok helyen nem észérvek alapján döntenek, hanem az épp aktuális divat szerint, akár a befektetők (VC - Venture Capitalists) is csak így adnak pénzt (nyilván nálunk kevésbé, de Amerikában annál inkább). A szerző szerint a Test Driven Development felesleges premature optimization, szerinte előbb legyen működő termék, aztán lehet optimalizálgatni. Ugyancsak nem veszi komolyan azokat, akik már az elején a skálázhatósággal nyaggatják.
3

Köszi, akkor mégsem én vagyok

eddig bírtam szó nélkül · 2012. Okt. 8. (H), 21.40
Köszi, akkor mégsem én vagyok a hülye... Kb. ez jött le belőle (hogy hülyeségnek tartja a TDD-t) és nem akartam elhinni, hogy valóban erről szól...
Plusz fogalmam sem volt, mit jelent a VC. (A VCS-ről nekem egy remote console management cucc jutott eszembe :-) )
4

Szerintem ez a post egy

BlaZe · 2012. Okt. 8. (H), 23.39
Szerintem ez a post egy pöttyet szélsőséges :) Van azért átmenet "a teszt hülyeség", meg a TDD között. És ha nem is TDD-vel indul egy startup, az egy öngól, ha durván át kell írni az egészet, hogy tesztelhető legyen. Márpedig a teszt egy fontos eszköze a minőségbiztosításnak, ez pedig joggal lehet elvárása a VC-knek.

A skálázhatósággal szintén ugyanez van. Utólag újracsinálni valamit mindig sokkal drágább, mint előre gondolkodni. És a gondolkodás nem azt jelenti, hogy egyből egy New York méretű szerverparkra kell tervezni a 20 useres startup rendszert. Mert ha a 20-ból lesz hirtelen sok, mert pl jó az alkalmazás, akkor az elég látogató és befektető lohasztó dolog, hogy "2 hónap múlva el fogjuk bírni a látogatókat, csak hozz még redbullt". És janoszen sorozatának 3. része óta tudjuk, hogy "nem lehet csak úgy megmarkolni egy programot, és bevágni egy clusterbe, hogy ott majd jól terheléseloszlik" :) Aki izzadt már vért nagy terheltségű éles alkalmazás alatt, mert "gyorsan" kellett megoldania a skálázhatóság problémáját, az ezt szerintem nem kérdőjelezi meg.

A lényeg, hogy a ló egyik oldalára se célszerű átesni (állatira tud fájni :)), ez a post meg nekem kicsit ilyen hangulatú volt. Bár kétségtelenül érdekes, köszi.
5

Illetve egy valamennyire

BlaZe · 2012. Okt. 8. (H), 23.56
Illetve egy valamennyire idevágó post:

http://www.theenterprisearchitect.eu/archive/2009/06/25/8-reasons-why-model-driven-development-is-dangerous
30

A poszt lényege pár szóban

tgr · 2012. Okt. 11. (Cs), 02.34
A poszt lényege pár szóban az, hogy mindenki hülye, csak a szerző helikopter. A TDD-ről még érintőlegesen sincs szó benne (abban a pár mondatban, ami azzal foglalkozik, valójában az automatizált tesztelésről beszél általában), csak arról, hogy a VC-k mennyire nem értenek szerinte ahhoz, amit csinálnak; amúgy nagyjából a mostanában divatos bankárellenességből átültetett közhelygyűjtemény az egész (nem a saját pénzüket kockáztatják, blah-blah, aki nem ért hozzá, elmegy tanácsadónak, blah-blah). Ha érdekel a téma, inkább intelligens VC-ket olvass, mint buta programozókat (Paul Graham-nek pl. remek esszéi vannak, és épp mostanában írt róla, mitől lesz sikeres egy VC: Black Swan Farming).
6

TDD != létező kód tesztelés

breakline · 2012. Okt. 9. (K), 03.02
Biztos lemaradtam valamiről, de a TDD-nek még az elmélet szerint sincs semmi köze a kódoptimalizáláshoz vagy a kódteszteléshez? Vagy csak én tudom rosszul? Mert emlékeim szerint a TDD arról szól, hogy a kódodat valós tesztadatok alapján javítod hogy a megfelelő működést elérd, itt még szó sincs optimalizációról, csak pusztán input-output szinten a programról.

Tipikus példa volt egy nyelvtani szerkezetekre építő algoritmus, ahol is a TDD szerint előbb a nyelvtani szabályok szerint működik a program, majd egyenként megnézed a kivételeket is (tesztadatokkal, innen jön a név), majd a végeredmény elméletileg a bemeneti halmaz nagy részére jó kell hogy legyen (hiszen az elejétől kezdve tesztelted). A kódoptimalizáció pl. gyorsítás csak utána jönne.

Egyébként a cikk maga érdekes, és semmi köze a TDD-hez, én egyébként egyetértek sok mindennel amit ír bár nyilván amerika kissé más terep.
7

Szerintem az az írás lényege,

Hidvégi Gábor · 2012. Okt. 9. (K), 07.51
Szerintem az az írás lényege, hogy előbb írjuk meg a kódot, működjön a program, és, miután beindul az üzlet, akkor álljon neki az ember a további optimalizációnak, aminek része a tesztelés vagy a skálázhatóság belövése, mert ezekre a dolgokra sok idő elmehet.
8

És hogy fog működni, ha nem

eddig bírtam szó nélkül · 2012. Okt. 9. (K), 08.24
És hogy fog működni, ha nem tesztel? :-)
Próbáltam TDD-t játszani, nekem nem ment, de ez nem a módszer hibája.
9

Mielőtt feltalálták a TDD-t,

Hidvégi Gábor · 2012. Okt. 9. (K), 08.34
Mielőtt feltalálták a TDD-t, akkor is működtek a programok.
10

És akkor is írtunk

eddig bírtam szó nélkül · 2012. Okt. 9. (K), 09.05
És akkor is írtunk automatizált teszteket. Persze nem a húsz soros scriptekhez... Csak kevés embernek jutott eszébe, hogy előbb írja meg a nem létező kódhoz a tesztet és csak utána a tényleges kódot.
11

Nem létező kódhoz teszteket?

Hidvégi Gábor · 2012. Okt. 9. (K), 09.24
Nem létező kódhoz teszteket? Minek?
12

A TDD-nek az a koncepciója,

inf · 2012. Okt. 9. (K), 10.37
A TDD-nek az a koncepciója, hogy egy kis teszt, egy kis kód, utána megint egy kis teszt, és megint egy kis kód. Ha nem tudsz egyszerű tesztet írni, akkor tervezési hibát vétettél. Így meg lehet spórolni egy csomó időt, mert a tervezési hibák nem egy későbbi fázisban derülnek ki, amikor már a rendszer jelentős részét újra kellene írni miattuk.

Szóval a TDD szerintem pont nem az a dolog, amivel példálózni kéne. Persze ettől függetlenül előfordulhat olyan eset, amikor a megrendelő szól bele szakmai dolgokba divat alapon, és ez annyira tényleg nem szerencsés.
14

Nagyon sok tervezési hiba

Hidvégi Gábor · 2012. Okt. 9. (K), 11.34
Nagyon sok tervezési hiba csak használat közben derül ki, ezeket nem tudod sehogy sem megúszni, minél bonyolultabb a rendszer, annál nagyobb valószínűséggel.
15

A TDD nem is ezek kivédésére

eddig bírtam szó nélkül · 2012. Okt. 9. (K), 11.46
A TDD nem is ezek kivédésére lett kitalálva.
16

A TDD szerintem szervesen

inf · 2012. Okt. 9. (K), 12.22
A TDD szerintem szervesen illeszkedik a SOLID elvekhez, és azokról leválasztva tényleg semmit nem ér... Ha valami nem stimmel az adott kóddal, akkor azonnal kiderül a tesztekből. Például ha túl bonyolult egy teszt, akkor valószínűleg SRP nem érvényesül, ha nem tudsz mockolni valamit, akkor meg valószínűleg inversion of control nem érvényesül, stb... Ha nem erre lett kitalálva, akkor mire?
18

Igazad van, ez is tervezési

eddig bírtam szó nélkül · 2012. Okt. 9. (K), 14.43
Igazad van, ez is tervezési hiba, erre nem gondoltam.
17

Ezt hiszem is, meg nem is, de

inf · 2012. Okt. 9. (K), 12.26
Ezt hiszem is, meg nem is, de biztosan vannak olyan tervezési hibák, amiket TDD-vel könnyebben ki tudsz védeni, mint amúgy, ha csak szimplán kódolnál. Persze lehet, hogy csak én írok alapból olyan kódot, ami hemzseg a tervezési hibáktól, és a létezés egy magasabb síkján ilyen mankókra, mint a TDD már nincs szükség, mert minden elsőre tökéletesre sikerül ... :-)
13

Nagyon durva közelítéssel:

eddig bírtam szó nélkül · 2012. Okt. 9. (K), 11.26
Nagyon durva közelítéssel: felvázolod, hogy az egyes osztályaid milyen interface-szel rendelkeznek a külvilág felé.
Írsz egy tesztet, ami ennek az interface-nek a működését teszteli. Amikor megakad - pl. azért, mert nincs mögötte meghívható kód - akkor "javítod" (megírod a tesztelni kívánt programrészt). Lefut a teszt. Ha sikeres, akkor újabb darabkához írod a tesztet stb.
Van benne ráció, nagyobb, jól átgondolt rendszereknél úgy érzem, nagyon is hasznos dolog.
(Ama bizonyos Robert C. Martin is eltökélt hívőnek tűnik e téren, bár nem jut eszembe, ki az, akire előszeretettel hivatkozik)

szerk: ja bocs, most látom csak, hogy inf3no már válaszolt...
19

Csak nekem volt az az

Tyrael · 2012. Okt. 9. (K), 16.19
Csak nekem volt az az erzesem, hogy cikk szerzoje valahogy sokkal kevesbe boldogul fejlesztokent, mint amennyire a sajat onertekelese alapjan kellene?
- van 100%os receptje, hogy hogyan szerezzen befektetot.
- van 100%os receptje, hogy hogyan szerezzen olcso/ingyen fejlesztot.
- a sajat uzleti tervenel jobbat meg sosem hallott.

Ezzel szemben egyre nehezebben talal munkat(pedig mar kevesebb penzert is menne), ahova felveszik, ott sem marad meg sokaig, es nincs semmi megtakaritasa.

A felhozott problemak kozott van 1-2, ami szerintem igaz (a hype sokat szamit a befekteto toborzasnal, 20 napos anyagi tartalekkal rendelkezo ceghez nem biztos, hogy erdemes menni), de minden pontban nagyon fekete-feher kepet fest, szandekosan kisarkitja szerintem a helyzetet.

Az itt kiragadott tema kapcsan(TDD) azt gondolom, hogy egy startupnal az egyik legfontosabb dolog a reszponzivitas, hogy minel rovidebb ido alatt tudj iranyt valtani(uj piac, uj funkcio, uj uzleti model, etc.).
Ha nincsenek unit/integracios teszteid (es ehhez egy build/integracios kornyezeted, ahol egy fuggetlen kornyezetben tudod futtatni ezeket), akkor semmi tamaszod nincs arra nezve, hogy az alkalmazas ugy mukodik, ahogy kell, es ami a nagyobb problema, hogy semmi informaciod nincs arra nezve, hogy egy kisebb/nagyobb modositas nem fog el eltorni valamit a rendszerben.

Es akkor a TDD egyeb elonyeirol, mint
- jobban atgondolt kod,
- vilagos, minimalis dependencia a komponensek kozott,
- konyebb karbantarthatosag a tesztek dokumentaciokent valo hasznalhatosaga miatt
meg nem is ejtettunk szot.

ps: tesztek nelkul azt sem latod, hogy mekkora technikai kolcsont vettel fel, es hogy mennyire vagy a fizetokeptelensegtol, szemelyes kedvencem Elizabeth Naramore Technical Debt cimu eloadasa a temaban.

Tyrael
24

Csak nekem volt az az

Hidvégi Gábor · 2012. Okt. 10. (Sze), 15.48
Csak nekem volt az az erzesem...
Igen. Semmi ilyenről nem ír, és (akár a többi írását elolvasva) kiderülhet, hogy ő egy programozó, de saját ötlete és pénze nincs saját vállalkozásra.

Az itt kiragadott tema kapcsan(TDD) azt gondolom...
Egy startupnál a lényeg, hogy minél előbb legyen működő szolgáltatás. Ha jól értem a TDD következményét, gyakorlatilag kétszer annyi idő lefejleszteni a kódot, mert a kimenet egyik fele teszt, a másik fele meg maga az alkalmazás.

A Wikipédiából:
Test-driven development is difficult to use in situations where full functional tests are required to determine success or failure. Examples of these are user interfaces, programs that work with databases
Tulajdonképpen akkor mire jó ez az egész? Azt tudod ellenőrizni, hogy működik az osztályod, de azt nem, hogy jó-e?
25

Ha jól értem a TDD

Poetro · 2012. Okt. 10. (Sze), 16.05
Ha jól értem a TDD következményét, gyakorlatilag kétszer annyi idő lefejleszteni a kódot

Nem. Pontosan annyi idő kell a kód lefejlesztéséhez, amennyi kell. Ha nincs teszt, legyen az bármilyen, akkor 5-10-szer annyi idő lefejleszteni a kódot, annyi hiba lesz a fejlesztés során.
26

Tulajdonképpen akkor mire jó

BlaZe · 2012. Okt. 10. (Sze), 16.38
Tulajdonképpen akkor mire jó ez az egész? Azt tudod ellenőrizni, hogy működik az osztályod, de azt nem, hogy jó-e?


Szerintem írták feljebb, de a lényege, hogy a kódod egyes részeit tudod vele tesztelni. Pl van egy metódusod:
 public int returnsWithFive() {
  return 5;
}
Erre írhatsz egy tesztet, ami megvizsgálja, hogy a metódus valóban 5-tel tér-e vissza:
@Test 
public void testReturnsWithFive(){
  assertEquals( 5, new TestedClass().returnsWithFive() );
}
Ennek így első ránézésre nincs túl sok értelme :) De képzeld el, hogy ez egy többezer soros kód közepén van, majd egyszercsak jön Pistike, és átírja a return 5-öt return 6-ra, mert úgy állnak neki a csillagok. Innentől kezdve ami a returnsWithFive() metódus helyes működésére épített, az borulni fog. Viszont ha lefuttatod a tesztet, ezt azonnal észreveszed, és ki tudsz osztani Pistikének egy nádpálcás verést, meg egy igazgatóit :)

És ha még jobb akarsz lenni, betolod az egészet egy CI-ba (pl jenkinsbe), ahol beállítod, hogy pollozza a verziókezelődet mondjuk 10 percenként, és ha Pistike commitolt valamit, akkor futtasson egy tesztet. És/vagy minden éjjel 4-kor. És az eredményről küld neked levelet. És lőn, automatizáltuk Pistike nádpálcás verését :)

Elnézést minden Pistikétől :)

Ez a Unit teszt. A TDD meg egy az ezen elvek mellett végzett ciklikus fejlesztés, ahogy már írták is. Vannak UI tesztek is, de az egy másik téma. Szóval lehet tesztelni UI-t is. Meg természetesen ott se áll meg a tudomány, ha egy tesztelt kód adatbázishoz próbál nyúlni.

Hogy tovább tart-e megírni egy ilyen kódot? Tapasztalat és kódbonyolultság függő. Mindenesetre az első refaktorálásnál, módosítási igénynél jó eséllyel borulsz tesztek nélkül, így ha tovább is tart, visszajön. Startupnál meg van rá némi esély, hogy ilyesmi előfordul :) Úgyhogy ez egy baromi nagy vérző seb ebben a postban, ahogy páran rávilágítottak. A többi ellentmondáson, meg egyéb butaságon kívül. A többit én nem olvastam, de ennek a postnak a legtöbb gondolatát nem tudom magamévá tenni.
28

Köszönöm a választ, majd

Hidvégi Gábor · 2012. Okt. 10. (Sze), 21.09
Köszönöm a választ, majd gondolkozom rajta, hogyan is tudnám hasznosítani.
29

Hogy tovább tart-e megírni

inf · 2012. Okt. 10. (Sze), 22.30
Hogy tovább tart-e megírni egy ilyen kódot? Tapasztalat és kódbonyolultság függő.

Az én tapasztalatom az, hogy nagyon erősen tapasztalat függő. Ez is olyan, amire rá kell érezni. Próbálkoztam vele, és eddig elég döcögősen ment. Érdemes megnézni, amit T.G. belinkelt fentebb a témában http://www.youtube.com/watch?v=fkrpMLzxWOo&feature=plcp, sokat lehet tanulni belőle. Nem minden lépésével értek egyet, én pl trükközés helyett írtam volna tesztet a "count neighbours"-re is, meg mondjuk szétkaptam volna jobban a kódot, de érdekes volt látni, hogy egyáltalán nem muszáj darabolni, vagy akár public interface-be tenni az ilyen metódusokat.

Mindenesetre az első refaktorálásnál, módosítási igénynél jó eséllyel borulsz tesztek nélkül, így ha tovább is tart, visszajön. Startupnál meg van rá némi esély, hogy ilyesmi előfordul :)

Módosítani mindig kell, mert mindig vannak új megrendelői igények, hogy na még ezt meg azt csapjuk hozzá. Arról meg nem is beszélve, hogyha nincsenek integrációs tesztjeid, akkor bármilyen felhasznált cuccnak a verzió váltása gondot okozhat. Ez mondjuk azért zűrös, mert általában ezekhez nem mellékelnek teszteket, csak leírást, hogy mi változott, ami meg azért nem annyira megbízható. Pl az előző verzió tesztjeinek a lefuttatásával könnyen ellenőrizhető, hogy mi az, ami ténylegesen máshogy működik, és esetleg rá lehet keresni. Nem nagyon van még tapasztalatom, hogy hogyan kell teljes lefedettségű projektet készíteni. Erről pl jó lenne egy cikk sorozat, vagy csak egy rövid leírás, már ha valakinek van írói vénája hozzá. Az a baj, hogy minél jobban keni valaki a témát, annál kevesebb ideje van írógatni... :S
20

Open Academy előadás

T.G · 2012. Okt. 9. (K), 18.44
Miért van az, hogy technológiákat, módszereket anélkül kritizálunk, hogy legalább azt tudnánk, hogy körülbelül miről szól? Mivel elkezdtem rendezgetni a számomra érdekes videókat, így ismét belefutottam az alábbiba: http://www.youtube.com/watch?v=fkrpMLzxWOo&feature=plcp
Szerintem kifejezetten hasznos anyag a témában érdeklődőknek! Hogy legalább tudjuk, hogy mit szeretnénk kritizálni. :)
21

fröcsögés

blacksonic · 2012. Okt. 10. (Sze), 13.04
elolvastam a fickó többi cikkét is, színtiszta fröcsögésnek tűnik szinte mindegyik
amiről fröcsög meg sokszor fogalma sincsen
22

Sok időd van, én az első két

inf · 2012. Okt. 10. (Sze), 14.07
Sok időd van, én az első két sort olvastam el ebből a cikkből, aztán lejött, hogy marhaságokat beszél :D

Nodejs-nél rászántam az időt, hogy utánanézzek, az azt ért szidalmaknak. A vége mindig az lett, hogy kiderült, hogy teljesen kisarkították a tényleges helyzetet, meg direkt rosszul megírt kódokra hivatkoztak... Azóta valahogy nincs időm ilyeneket olvasni, hogy ez ilyen szar, az meg olyan szar. El tudom én is dönteni, hogy kell e vagy sem.
27

atporgetve

blacksonic · 2012. Okt. 10. (Sze), 19.23
A vegigolvasas lehet tulzas, atfutottam, mert hosszu bekezdes elejen mar latszodott h alapveto dolgokkal nincs tisztaban technikai teren :)
23

igazság

Hidvégi Gábor · 2012. Okt. 10. (Sze), 14.19
elolvastam a fickó többi cikkét is, egy-két apróság kivételével egyetértek vele
nagyon jól átlátja, hogyan működnek a dolgok
31

A témához kapcsolódó írás

BlaZe · 2012. Okt. 17. (Sze), 13.41
A témához kapcsolódó írás Verhás Pétertől: http://tifyty.wordpress.com/2012/10/16/nincs-felesleges-teszt/

Java blog, de itt inkább az elvekről van szó, úgyhogy érdekes lehet PHP fejlesztőknek is.