Hejsa

Jeg holder et kursus i TDD d. 26 marts og har allerede bestemt mig for en del af indholdet. Jeg vil blandt andet snakke om unittest, tdd (selvfølgelig), dependency injection (evt. med brug af castle), mocks.

Det kunne være sjovt at få en lille diskussion igang. Er emnerne tilstrækkelige for at kunne arbejde videre med TDD? Mener du at jeg mangler et super-vigtigt emne? I bund og grund, hvad skal et kursus omkring TDD indeholde?

Hilsen Thomas

Kim Dalsgaard

Jeg synes personligt, at det vigtigste at bibringe kursister er hvad er unit er når man skal unitteste. Jeg ser alt for mange 'fede' unittest der fagner alt for meget kode.

  • 0
  • 0
Thomas Ardal

Helt enig. Jeg gjorde et rimeligt stort nummer ud af netop dette emne på det gå-hjem-møde jeg holdte i februar omkring TDD.

Tak for input :)

  • 0
  • 0
Frank Døssing

Med grønne fingre indenfor unittest og TDD er min erfaring at det forudsætter at de klasser der skal testes har udgangspunkt i et interface, ellers kan det være komplekst at unitteste. Er det ikke også gældende i forhold til oprettelse af mock objekter?

Hvad siger jeres erfaring?

Hvad med et kursus i Kbh?

hilsen Frank

  • 0
  • 0
Kaspar Lundsby

Er det et kursus eller en præsentation af TDD, du skal holde? For hvis det ikke blot er en præsentation, vil jeg mene, det er en rigtig god idé med hands-on experience. Det er jo meget fint at se TDD på papiret, men at prøve det i praksis giver et helt andet indblik i tilgangen, der skal tages i udviklingen. Det kunne måske også være interessant at se forskellene på et kodestykke, der er udviklet med TDD, og et "normalt"-udviklet stykke kode.

  • 0
  • 0
Thomas Ardal

Frank: Umiddelbart ser jeg ikke noget krav til at den klasse du tester skal ligge bag et interface. Det der tit of ofte er vigtigt er (også ved brug af mocks), at de afhængigheder som den klasse du tester, er "skjult" bag interfaces. Men du har ret i, at den klasse du tester højst sandsynlig vil indgå som en afhængighed til en anden klasse, så du vil nok implementere et interface alligevel. De fleste mock frameworks idag kan dog mocke andet end interfaces, men det stiller selvfølgelig nogle krav til den klasse du mocker. I .NET skal metoderne eksempelvis erklæres virtual.

Umiddelbart er der ikke planlagt noget kursus i Kbh, medmindre det selvfølgelig er noget der er overvældende interesse for :)

Kaspar: Gå-hjem-mødet i februar var en præsentation, mens kurset i marts er et egentligt kursus. Det vil sige at der vil komme en masse hands-on, således at kursus-deltagerne selv vil få lejlighed til at skrive unit tests og blive "test-drevne".

Tak for input til jer begge.

  • 0
  • 0
Frank Døssing

Kurset lyder rigtig interessant - det er vel ikke sådan at der er planlagt en gentagelse på et senere tidspunkt? Og som en idé til en efterfølger ser jeg gerne et kursus omhandlede automatiserede build procedure, med MSBuild og CruiseControl...

hilsen Frank

  • 0
  • 0
Thomas Ardal

Hvis der er tilslutning til det, vil kurset blive holdt flere gange. Vi havde faktisk tidligere et opslag på et kursus indeholdende både unittest, TDD, Continous Integration osv. Men det var da ikke særlig stor tilslutning til. Men umiddelbart synes jeg også, at netop disse emner går rigtigt godt i spænd. Måske at jeg skulle arbejde tilbage i den retning. Hvad mener folk om dette? Kan man forsvare over for sin projektleder, at man gerne vil deltage i et 1 dags kursus i TDD, eller skal der mere kød på, i form af msbuild, cc.net osv.?

  • 0
  • 0
Frank Døssing

jeg mener at der er rigeligt stuff til 1 dag med CI. Personligt har jeg brug for noget praktisk input til brugen af MsBuild og CruiseControl. Erstatter MsBuild f.eks Ant 100%? Integration af automatisk database-build? VersionsStyring af komponenter osv..

Der findes forskellige tutorials om emnet, men enten syntes jeg de er for simple eller for komplekse. Så in-between vil være at foretrække.

Men hvor udbredt er brugen af CI rundt omkring i det danske udvikler-miljø?

  • 0
  • 0
Ole Østergaard

Hej Frank!

Du spørger hvor udbredt brugen af CI er i det danske udvikler-miljø. Jeg kender ingen der kan undvære det... for 5 år siden var det måske ikke så udbredt, men jeg kan slet ikke forestille mig nogen professionelle projekter uden CI.

Hvis man har et udviklerteam der laver integrationstests i stedet for rigtige unit-tests, vil test-delen af CI-kørslen med tiden blive så langsom (pga. tests der laver alt for mange database-forespørgsler) at CI bliver knap så anvendeligt som ellers. Det er synd.

Men man bruger jo stadig CI selvom det tager en halv time at bygge og køre samtlige tests, og det er da bestemt bedre end ingenting. Det kunne bare være så meget bedre :-)

Hvis nogen af jer har gode indgangsvinkler til at få folk til at fokusere mere på at lave tests uden databaseforbindelse, hører jeg meget gerne om det. Man har jo tit den holdning at "arh, den her test tager godt nok 7 sekunder at køre, men pyt nu med det...". Jeg har efterhånden gjort det til et princip at slukke for min database før jeg begynder udvikling af ny funktionalitet - så kan jeg lære at undgå databasetunge tests :-)

  • 0
  • 0
Thomas Ardal

Jeg er helt enig. På den anden side bør man aldrig glemme integrationstest. Min holdning er, at man skal gå efter en masse unit tests, færre integrations tests og få system tests. Hvorfor? Fordi jo nærmere vi kommer system test, jo længere tid tager testene at udføre og jo mere manuelt arbejde er der som regel forbundet med testen.

  • 0
  • 0
Thomas Gravgaard

Jeg tror at hvis man holder kursus en enkelt dag i TDD for folk der aldrig har Unit testet før. Så bør man bruge mest muligt tid på bare at lære folk at unitteste i forskellige situationer. Ting jeg ville synes man skulle komme ind på var:

Grundlæggende UT. TDD. Forskel på Unit test, system test, integration test. Test af særlige miljøer: databaser, eksterne systemer (mail, web services, sockets...) Granularitet af tests. Strukturering af test suites for god CI performance. Error cases vs. good cases kvotient i test cases. Code coverage. Måske Mocks - men det kan godt være det bliver for tight.

Har selv haft tanker om at køre et TDD kursus i kbh området. Men fik aldrig rigtigt gjort alvor ud af det. Ikke for at mave mig ind på dit område Thomas. ;-)

  • 0
  • 0
Thomas Ardal

Tak for input Thomas.

Jeg blev lidt nysgerrig omkring dit punkt "Strukturering af test suites for god CI performance". Er det noget du vil uddybe? Litteraturen fortæller os jo, at automatiserede tests ikke må være afhængige af hinanden. Men på den anden side vil vi jo også gerne have gennemført vores build så hurtigt som muligt. Så der er en konflikt der, som jeg ser det.

Og til sidst omkring dine tanker om et TDD kursus i kbh. Jeg har på ingen måde eneret på dette emne. Tværtimod. Det er i min interesse, at så mange som muligt mestrer test og TDD disciplinen. Så du "maver" dig bare alt hvad du vil :o) For øvrigt mener jeg ikke, at Trifork (firmaet jeg arbejder for) holder åbne kurser på Sjælland. Så min pointe er: jo flere forskellige kursusmuligheder jo bedre. Så kan jeg nemlig selv tage på TDD kursus og høre hvad andre mener om emnet ;)

  • 0
  • 0
Frank Døssing

Hr. Gravgaard,

Jeg syntes det lyder interessant med et TDD kursus omkring Kbh. Jeg har et par ideer vi måske kunne drøfte og igangsætte noget? Du må meget gerne sende mig en mail på frankdossing_at_cimbex.dk.

  • 0
  • 0
Thomas Ardal

Hvis jeg kan, vil jeg også meget gerne bidrage med noget til et evt. kursus i Kbh. Jeg kan mailes på thomasardal_at_gmail_dot_com.

Med hensyn til begreberne systemtest, integrationstest og unittest så tror jeg, at alt for mange misforstår dem, netop fordi der ikke er nogen fast definition af dem. Her er min opfattelse:

Unittest: test af selvstændig enhed f.eks. en klasse. En sådan test må ikke være afhængig af andre klasser eller resourcer. Afhængigheder mockes eller stubbes. Man kan selvfølgelig argumentere for, at indbyggede typer i de forskellige sprog ikke skal mockes. Generelt er det nok også svært at holde testen på een klasse af gangen, men forsøg at holde dig indenfor samme komponent i det mindste.

Integrationstest: test af samspillet mellem forskellige klasser eller assemblies/jars. Det er efter min opfattelse ok at være afhængig af en database i dine integrationstests.

Systemtest: test af det fulde system fra brugergrænseflade til database.

Efter min mening bør du have flest unittests, færre integrationstests og få systemtest. Hvorfor? Fordi jo mere du bevæger dig over mod systemtest, jo mere omfattende og tidskrævende bliver dine tests at udføre.

  • 0
  • 0
Kasper Sørensen

Evt. kan man også inkludere en letvægts database i selve testwaren. Selv plejer jeg at inkludere en embedded Derby database (fordi jeg primært laver java projekter) som så fungerer som test database. Det giver mig både muligheden for at have en "ægte" database og samtidig kan mine tests flyttes fra maskine til maskine og være uafhængige af en central db-server.

  • 0
  • 0
Mikkel Bjerg

Jeg mener nu stadig (som Ole også giver udtryk for) at man skal tænke sig meget grundigt om inden man begynder at lave tests som bruger databasen. Man skal i hvertfald være bevidst om at det så ikke er unittests man laver men derimod integrationstests, og at de derfor ikke vil blive kørt ved alle byg, men måske kun ved natlige byg o.lign.

Det jeg oplever som det største problem er at folk ikke er bevidste nok om hvornår de skriver unittests og hvornår de laver integrationstests.

Om det så er fornuftigt at inkludere en ltvægts-database i testwaren er et helt andet spørgsmål. Det største problem jeg ser ved det, er når man så begynder at have forskellig kode til de forskellige databaser, fordi de ikke opfører sig HELT ens. Så er man ude i at få testet noget kode, som næsten ligner det man gerne vil køre når koden skal i produktion

  • 0
  • 0
Kasper Sørensen

Ja det kommer jo også enormt meget an på hvad det er for et system vi taler om. I ovenstående eksempel er der tale om et database-værktøj som skal kunne fungere med mange forskellige slags databaser og håndtere dem forholdsvist ens (på trods af forskellige i database drivers osv) og så er det jo netop dén unit man ønsker at teste.

Definitionsmæssigt er det måske nærmere en integrationtest, men hvis éns produkt er integrationstungt så er integrationtest også en del af dét man ønsker testet i continous integration.

  • 0
  • 0