Testable code GUI applicaties

[armageddon_2k1]

Ik zit me een beetje in te lezen als ik JUnit wil gebruiken bije en GUI applicatie. Ik ging er natuurlijk vanuit dat je zo veel mogelijk logica uit je GUI wil houden dus het verrast me ook niet dat ik dat veel zie.

Ik kwam uiteindelijk op het volgende artikel:
The Humble Dialog Box

De bottomline van het artikel vat het als volgt samen:

1. Create a class for the smart object, and an interface class for the view. Pass the
view to the smart object
2. Develop commands against the smart object, test first. Write your tests against a
mock view.
3. Create your dialog class and implement the view interface on it. Gestures on the
dialog should delegate to commands on the smart object. Calls from the smart
object to the dialog should resolve to simple setter methods.
When you follow these steps, you end up with tested code and a great interface for
driving acceptance tests programmatically.

Ik zie in dat je hier goede testable code mee kan krijgen. Maar een ding druist hier in tegen mijn gevoel. Je hebt dus een object/model waar alle logica in plaats vind, en die pass je dus een Interface van de view. Maar voor mijn gevoel wil je de model-objecten helemaal geen referentie naar hun view meegeven. Het kan zo maar zijn dat ik een console applicatie wil maken en helemaal geen view wil hebben. Dan zou ik dus een view moeten implementeren die helemaal niks doet. Voor mijn gevoel zou het toch andersom zijn, namelijk een View welke een Interface van het model met zich mee draagt. Het is namelijk die View welke het object manipuleert en het resultaat wil tonen.

Hoe is jullie mening hierover en zijn er pro's/con's die ik over het hoofd zie?

[bwerg]

In een console-applicatie kan je ook een view-interface implementeren natuurlijk. En die view die print dus naar de console (en die gaat dan over de vorm waarin het wordt geprint, of er bijvoorbeeld ascii-art wordt gebruikt of niet). Als je in je model meteen naar de console print bevat het model dus al een view, ook al is het grafisch niet zo mooi.

Voor de opzet kun je gewoon een bestaand pattern gebruiken, zoals MVC met Observer/Observable.

[Verwijderd]

Let op dat niet AL je logica in die class komt.
Alleen code om de view te ondersteunen (interactie, data binding, etc).

Business logica / modellen / services / helpers etc. ontwikkel je ook weer in losse componenten die ook weer onafhankelijk van elkaar te testen zijn.

Belangrijkste is om dit gewoon eens uit te testen.

En een key factor in unit testen is ALTIJD beginnen met je unit tests. (dus niet de code voor je view/controller/model eerst schrijven)

- Schrijf eerst de test (deze compileert uiteraard niet, want de code die je aanroept bestaat niet)
- implementeer het component wat je wil testen minimaal
- maak voor alle dependencies een mock (of gebruik een mock framework)
- compile / draai je tests
- refactor
- start bij 1.

Alleen als je áltijd eerst met unit tests schrijven begint, zal je de relaties tussen de verschillende componenten beter begrijpen, 10x vastlopen en je hoofd breken en zo ervaring op doen voor toekomstige architecturen

[Hydra]

TDD is leuk maar ik zie dat eigenlijk nooit in de praktijk gebracht worden.

[Verwijderd]

Dan kijk je naar de verkeerde projecten .

TDD is een belangrijk process in Agile software ontwikkeling en continuous integration. Het is een onderdeel van de kwaliteits controle van grotere projecten.

Al snel denk je bij kleinere projecten of prive projecten: ,,Laat maar, ik vind het leuker échte code te schrijven'. Maar zoals ik al zei, je leert pas echt goede code schrijven als je begint met de tests.

Pas dan zie je namelijk dat je op bepaalde plekken in je code dingen wil doen, die jouw tests niet toelaten. Hetzij door een architectuur fout. of bijvoorbeeld een regression bug.

edit: overigens ben ik ook niet zo van dat kamp. Maar als een project groter wordt, zorg ik dat kritieke code zeker in een (unit) test staat. Oa. om regression bugs tegen te gaan

[ Voor 13% gewijzigd door Verwijderd op 12-11-2012 11:00 ]

[Hydra]

Ik zeg niet dat het geen goed idee is, ik zeg dat het alleen vrijwel nooit toegepast wordt. Juist de meeste grote projecten moeten 'snel snel snel' en is unit testen een ondergeschoven kindje, laat staan dat er met TDD gewerkt wordt.

[Woy]

Verwijderd schreef op maandag 12 november 2012 @ 10:58:
Dan kijk je naar de verkeerde projecten .

TDD is een belangrijk process in Agile software ontwikkeling en continuous integration. Het is een onderdeel van de kwaliteits controle van grotere projecten.

Unit tests schrijven != TDD

Test Driven Design gaat veel verder, aangezien het principe daar is dat je begint met de testen schrijven en op die manier het design vastlegt. Voor Agile/CI is het inderdaad belangrijk dat je een goede set tests hebt omdat je op die manier snel fouten detecteerd, maar het hoeft echt niet perse via TDD opgezet te zijn.

[ Voor 31% gewijzigd door Woy op 12-11-2012 11:08 ]

[Hydra]

Woy schreef op maandag 12 november 2012 @ 11:06:
Unit tests schrijven != TDD

Hij zei in z'n eerste post "schrijf eerst de test" dus ik denk dat 'ie dat wel snapt.

[Woy]

Hydra schreef op maandag 12 november 2012 @ 11:09:
[...]


Hij zei in z'n eerste post "schrijf eerst de test" dus ik denk dat 'ie dat wel snapt.

Dan snap ik de opmerking dat het belangrijk is voor Agile/CI niet helemaal. Je zou natuurlijk kunnen stellen dat je zonder TDD geen goede test-set kunt hebben, maar anders is het niet noodzakelijk om TDD toe te passen bij Agile/CI.

Zelf heb ik nog nooit een project gezien wat echt TDD was. Ik zie wel regelmatig dat er ideeën uit TDD worden gebruikt, maar echt puur TDD ben ik nog nooit tegen gekomen.

[ Voor 17% gewijzigd door Woy op 12-11-2012 11:14 ]

[Hydra]

Woy schreef op maandag 12 november 2012 @ 11:13:
Dan snap ik de opmerking dat het belangrijk is voor Agile/CI niet helemaal. Je zou natuurlijk kunnen stellen dat je zonder TDD geen goede test-set kunt hebben, maar anders is het niet noodzakelijk om TDD toe te passen bij Agile/CI.

Mee eens.

Zelf heb ik nog nooit een project gezien wat echt TDD was. Ik zie wel regelmatig dat er ideeën uit TDD worden gebruikt, maar echt puur TDD ben ik nog nooit tegen gekomen.

Ik heb hetzelfde. Je merkt ook dat vooral in het begin vol goede moed begonnen wordt met het netjes unit-testen van alle componenten maar vaak komt er ook gewoon enorm de klad in nadat het project vordert. Het probleem met het schrijven van unit tests is dat het gewoon extreem saai is, en de meeste developers liever problemen oplossen dan 'saai werk' doen.

Wij hebben hier ook in princiepe de regel dat er voor elke class een corresponding test moet zijn, maarja, niemand die dat afdwingt.

[Woy]

Heel erg herkenbaar inderdaad.

[Verwijderd]

@Hydra Je hebt helemaal gelijk, snel snel opleveren en dure onderhoudscontracten om zooi op te ruimen. zo werkt het veelal wel ja :-)

@Woy Ik ben daar wat kort door de bocht ja, maar een goede test-set hebben, betekent dat je OF al zoveel ervaring hebt met code architectuur, dat je je integration tests later kan toevoegen, zonder je hele codebase om te gooien OF dus wél (een beejte) gebruik maakt van TDD.

En OP heeft verder geen ervaring met unit tests in het algemeen, dus noemde even wat steekwoorden waar hij zelf weer verder mee zou kunnen komen.

edit: daarom zie je de laatste jaren het TDD kamp meer naar een BDD kamp verschuiven :-)

[ Voor 7% gewijzigd door Verwijderd op 12-11-2012 11:21 ]

[Janoz]

Veel maat software is dan vaak ook niet meer dan een uitgebreide database frontend. Unittesten daarvan worden wel heel triviaal.

Er is echter 1 onderdeel waar TDD ontiegelijk handig en productief werkt: Bugfixing. Dat kan in een nieuw project of in de onderhoudsfase zijn. Eerst zorgen dat je met een test de bug na kunt spelen en dan fixen.

[Verwijderd]

@Janoz

jep. Neem bijvoorbeeld het NHibernate project. Daar dwingen ze je zowat een test aan te leveren, anders wordt er niet eens naar gekeken.
Andere opensource projecten zie ik dat ook vaak. Schrijf maar een isolatie. het zei in een bestaand test project, hetzei via een try-out console app.. maar lever IETS aan wat draait en faalt. zodat we dat in de toekomst ook kunnen draaien en het nóóit meer terug komt. (wederom: goed tegen regression bugs)

[MTWZZ]

Hydra schreef op maandag 12 november 2012 @ 11:18:
Ik heb hetzelfde. Je merkt ook dat vooral in het begin vol goede moed begonnen wordt met het netjes unit-testen van alle componenten maar vaak komt er ook gewoon enorm de klad in nadat het project vordert. Het probleem met het schrijven van unit tests is dat het gewoon extreem saai is, en de meeste developers liever problemen oplossen dan 'saai werk' doen.

Wij hebben hier ook in princiepe de regel dat er voor elke class een corresponding test moet zijn, maarja, niemand die dat afdwingt.

Niet alleen saai, je komt ook vaak code tegen waarvoor het niet heel zinnig is om een test te schrijven. Checken of een constructor wel of niet z'n argumenten in private fields zet bijvoorbeeld.

NCrunch is wel een fijne tool om er zelf zicht op te houden wat er van een class gecovered wordt door een test doordat je een visuele feedback hebt.

[Hydra]

Verwijderd schreef op maandag 12 november 2012 @ 11:23:
@Janoz

jep. Neem bijvoorbeeld het NHibernate project. Daar dwingen ze je zowat een test aan te leveren, anders wordt er niet eens naar gekeken.
Andere opensource projecten zie ik dat ook vaak. Schrijf maar een isolatie. het zei in een bestaand test project, hetzei via een try-out console app.. maar lever IETS aan wat draait en faalt. zodat we dat in de toekomst ook kunnen draaien en het nóóit meer terug komt. (wederom: goed tegen regression bugs)

Dat is vooral een drempel om te voorkomen dat mensen met "hij doet het niet" bugs komen. Iets dat je in een OS project mee weg komt, maar in echte projecten kun je van gebruikers niet eisen dat ze met code komen natuurlijk.

Daarnaast zijn unit-tests niet bedoeld om code in samenhang te testen, daarvoor heb je integratie-tests.

Maargoed, dit gaat wel erg offtopic. De TS wil GUI code testen en baseert zich op een artikel van meer dan 10 jaar oud over C++ dat ik persoonlijk niet zo relevant meer vindt. Als je in C# via het MVVC model ontwikkeld is hoe en waar je unit-test vrij voor de hand liggend. De strekking van het artikel, dat je je GUI controls zo 'dom' mogelijk wil houden, is m.i. een open deur in 2012.

MTWZZ schreef op maandag 12 november 2012 @ 11:26:
Niet alleen saai, je komt ook vaak code tegen waarvoor het niet heel zinnig is om een test te schrijven. Checken of een constructor wel of niet z'n argumenten in private fields zet bijvoorbeeld.

Ik schrijf sowieso geen unit-tests voor simpele getters/setters en dat soort zaken. Die zooi wordt toch gegenereerd.

NCrunch is wel een fijne tool om er zelf zicht op te houden wat er van een class gecovered wordt door een test doordat je een visuele feedback hebt.

NChrunch lijkt me een prima tool, alleen ben ik geen groot voorstander van de "code coverage" metric. Zaken zoals simpele getters/setters hoeven m.i. geen unit tests. Bij andere methoden wil je juist een hele zwik testcases voor een enkele methode om verschillende combinaties van inputs te testen.

[ Voor 53% gewijzigd door Hydra op 12-11-2012 11:31 ]

[Verwijderd]

Genoeg stof voor een avondje googlen @armageddon_2k1 ;-)

[armageddon_2k1]

Ja, gelukkig doe ik dit allemaal puur hobbymatig. Ik gebruik unit tests al veel voor mathematisch ingewikkelde modules die ik schrijf en daar heeft de waarde zich voor mij erg goed bewezen, alleen met een GUI raak ik een beetje in de knoop.

Ik denk dat ik inderdaad de MVC met Observer/Observable eens wat nauwer ga bekijken.

Dan vind ik het nog steeds vreemd dat in het artikel dat ik aanhaal dat daar een referentie naar de view gegeven wordt in het 'model'. Dat lijkt mij pertinent onjuist, maar ik vermoed dat het dus ook meer een controller is met wat simpele logica om het model en de view aan elkaar te knopen. Het model is hier echter zo simpel dat het in de controller gepropt is.

[Verwijderd]

Dat denk ik ook ja.

Ik ken java niet zo goed, maar bekijk ook event het MVVM (model view viewmodel) pattern. Dat sluit vaak beter aan bij interactieve GUIs dan MVC.

[MTWZZ]

Hydra schreef op maandag 12 november 2012 @ 11:28:
[...]


NChrunch lijkt me een prima tool, alleen ben ik geen groot voorstander van de "code coverage" metric. Zaken zoals simpele getters/setters hoeven m.i. geen unit tests. Bij andere methoden wil je juist een hele zwik testcases voor een enkele methode om verschillende combinaties van inputs te testen.

offtopic:
De code coverage gebruik ik ook niet zo maar het is een mooie manier om bij complexe methods te zien welke paden nog niet geraakt worden

[Grijze Vos]

Dat artikel lijkt een voorschot te nemen op MVVM. Waarbij het model dat ze dus omschrijven een viewmodel is. In die context is het prima wat daar gebeurt.