[alg] gui schrijven zonder gui?*

[Alarmnummer]

Ik gebruik al een tijd unit tests om mijn code te testen, maar het enigste dat me erg irriteerd is dat gui vrij lastig te unit testen is. Ik heb intussen op de junit site lopen bladeren naar gui unit tests addons, maar dit zijn voornamelijk scripts programma`s waarmee je dus automatisch op knoppen ed kan drukken.

Ik zat zelf meer te denken om de gui logica volledig uit de gui te trekken en de gui echt te laten vervallen tot niets meer dan de opbouw van grafische objecten. Je scheidt de grafische van de logica aspecten van de gui. De logica plaats je dan in een nieuw object, en dit object kan volledig los van de gui functioneren, je zou er dus voor kunnen kiezen om niet eens een gui erop aan te sluiten.

Voor normale toepassingen heb je hier totaal niets aan, maar voor unit testen lijkt me dit erg handig. Ipv een scherm als in en uitvoer, plaats je nu je eigen stub erop waarmee je alles kan afvangen + aansturen wat op je gui plaats vindt.

Het enigste probleem aan deze oplossing is de toegenomen complexiteit. Mijn vraag is of dit het waard is en of er misschien andere/betere oplossing voor zijn.

ps:
ik weet niet of dit eigelijk het juiste forum hiervoor is, doordat er ook weinig animo was voor: [rml][ Alg] wie unit-test er allemaal?[/rml]

[alienfruit]

Zelf maak ik me eigen gui componenten in een vast stramien, waarbij er sprake is van verschillende classes als eerste heb de klasse TMyControl, dit control heeft een klasse LookAndFeelFactory dit is een implementatie van de factory pattern, deze maakt een instantie van de klasse TLookAndFeelController. Dit is een klasse die alles afhandelt van de component i.e keyboard, mouse events maar ook het tekenwerk. In principe zou je weer een instantie van een klasse kunnen maken die weer het tekenwerk afhandeld, zodat dit ook gescheiden is van de controller-object. Op deze manier kun je op een gemakkelijke manier de look-and-feel van een control aanpassen, door een andere TLookAndFeelController te gebruiken en/of de painter-klasse te wijzigen.

Enige twist punt die er kan zijn is of je de controller buiten de TMyControl plaatst... Tot heden werkt dit model prima.

De Controller wordt als volgt aangeroepen:

ControllerInstance.MouseDown( Shift, Key, X, Y );

[Verwijderd]

Testen van je gui aan de hand van stories. Van te voren precies vast leggen hoe en wat de gebruiker krijgt te zien en moet doen. (Geen technische verhalen over hoe dingen intern gebeuren)

[Alarmnummer]

Verwijderd schreef op 20 October 2003 @ 15:03:
Testen van je gui aan de hand van stories. Van te voren precies vast leggen hoe en wat de gebruiker krijgt te zien en moet doen. (Geen technische verhalen over hoe dingen intern gebeuren)

Ik heb het over unit testen en niet over acceptance tests. Ik wil dus net zoals ik mijn niet gui objecten unit test, ook mijn gui objecten op dezelfde manier doorfluiten.

Dus ik heb hier niets aan.

[MSalters]

Ik weet niet welke GUI je gebruikt, maar bied je GUI nnet de mogelijkheid van externe inspectie?
Binnen LogicaCMG hebben we behoorlijk wat testervaring, en zijn we hier eerder tegenaangelopen. We hebben daarom al wat standaardcomponenten om hiermee om te gaan. Bij Qt bijvoorbeeld is het relatief makkelijk om test-code aan alle widgets, zowel standaard als user-defined te hangen.

[Alarmnummer]

MSalters schreef op 20 October 2003 @ 15:13:
Ik weet niet welke GUI je gebruikt, maar bied je GUI nnet de mogelijkheid van externe inspectie?

Er zijn mogelijkheden om dat te doen. Je kan met Swing (dat gebruik ik dus) componenten gaan opvragen en daar kunstmatig acties op laten uitvoeren/uitlezen/aanpassen etc. En er zijn unit test addons die dat een stuk makkelijker maken.

Maar het lijkt me lastig om een bepaalde flow hierin te gaan volgen. Ik heb bv een redelijk 'complexe' flow bij het saven van een of andere sessie. Misschien is er geen sessie actief, wat dan. Misschien is er wel een actief, wil je dan gaan saven of heb je misschien op cancel gedrukt. Als je wilt saven, en het saven is niet goed gegaan, wat dan?

Het lijkt me lastig om iedere keer schermen op te vragen. Ik heb liever objecten die ik als een soort nepgui kan aansluiten op mijn gui-logica object kan aansluiten en die aan te sturen/af te luisteren.

[ Voor 5% gewijzigd door Alarmnummer op 20-10-2003 15:30 ]

[alienfruit]

Bij mij weten worden GUI gebruikt voor terugkoppeling naar de gebruiker, wat het een stuk moeilijker maakt om dit automagisch te testen. Voor classes/units werkt dit perfect, maar voor GUI lijkt me dit een stuk lastiger. Daarom zou je ook altijd gebruik moeten maken van testpanels die tot de (verschillende) doelgroepen behoren.

Of je zou AI zou moet kunnen mkaen dat het verschillende doelgroepen kan nabootsen en zodoende ook op die manier de programmatuur testen. Lijkt mij nog een behoorlijke opgave.

[Infinitive]

Naast de typische imperatieve manier om GUI's te beschrijven, zijn er ook andere manieren. Kijk voor de grap eens naar fudgets.

Vraag me verder niet wat dit met het topic te maken heeft, maar ik las de topic titel "gui schrijven zonder gui" en dit kwam in me op...

[Alarmnummer]

alienfruit schreef op 20 October 2003 @ 20:53:
Bij mij weten worden GUI gebruikt voor terugkoppeling naar de gebruiker, wat het een stuk moeilijker maakt om dit automagisch te testen. Voor classes/units werkt dit perfect, maar voor GUI lijkt me dit een stuk lastiger. Daarom zou je ook altijd gebruik moeten maken van testpanels die tot de (verschillende) doelgroepen behoren.

Het hoeft niet zo heel veel anders te zijn imho. Als je de logica volledig uit de gui trekt, dan heeft die logica een bepaalde invoer en een bepaalde uitvoer. Daarop zou je je unit tests kunnen aansluiten.

Of je zou AI zou moet kunnen mkaen dat het verschillende doelgroepen kan nabootsen en zodoende ook op die manier de programmatuur testen. Lijkt mij nog een behoorlijke opgave.

Niet zo moeilijk doen he *kijkt al helemaal angstig om zich heen*

[Alarmnummer]

Infinitive schreef op 20 October 2003 @ 21:21:
Naast de typische imperatieve manier om GUI's te beschrijven, zijn er ook andere manieren. Kijk voor de grap eens naar fudgets.

Ik zal er even naar kijken.

Vraag me verder niet wat dit met het topic te maken heeft, maar ik las de topic titel "gui schrijven zonder gui" en dit kwam in me op...

Dat maakt niet uit.. Topics die niet meer gaan over het startonderwerp zijn meestal de leukste.

Ik zit zelf eraan te denken om de opbouw van gui ook niet eens meer in java te doen. Ik ben dan alleen nog de schrijver van alles behalve gui, en iemand anders kan met XML (een manier dat ik al een aantal keren ben tegengekomen) de gui opbouwen.

[Verwijderd]

Mijn ervaring met het unittesten van GUI is zeer laag (zeg maar gerust: nooit gedaan ), wel unittest ik altijd mijn entity en control objecten voor zover dit mogelijk is, al dan niet geautomatiseerd.

Wat ik mij afvraag is: waarom wil je je GUI unit testen? De GUI zou in de ideale situatie geen logica mogen bevatten, voordat de integratie heeft plaats gevonden. De enige logica die ik me kan voorstellen is dat de juiste events worden getriggerd, zodra met gebruik maakt van de GUI. Dit test ik zelf door altijd wat simpele messageboxes achter de events te zetten met daarin informatie over het object dat het event vuurde. Zo kun je je GUI redelijk makkelijk en simpel unittesten.

Je GUI opbouwen vanuit XML is natuurlijk wel een manier om heel zeker van je zaak te zijn dat de GUI geen fouten bevat.

Niet echt een oplossing maar meer een paar vragen / opmerkingen... leuke discussie overigens

[Alarmnummer]

Verwijderd schreef op 21 October 2003 @ 11:17:
Wat ik mij afvraag is: waarom wil je je GUI unit testen? De GUI zou in de ideale situatie geen logica mogen bevatten, voordat de integratie heeft plaats gevonden. De enige logica die ik me kan voorstellen is dat de juiste events worden getriggerd, zodra met gebruik maakt van de GUI.

Gui (acties ed) bezitten bij meestal wat glue om allerlei non gui objecten aan te sturen. En je loopt sowieso met complexe flow problemen te werken zoals bv aanmaken van een nieuwe iets..

wil je de oude saven? ja nee..
is er iets bij het saven mis gegaan? ja nee..
wil je doorgaan met het beginnen van de nieuwe sessie als er iets mis is gegaan? ja nee... etc etc..

Dit zijn dingen die ik echt niet ga verplaatsen naar objecten die niets met de gui te maken hebben

Dit test ik zelf door altijd wat simpele messageboxes achter de events te zetten met daarin informatie over het object dat het event vuurde. Zo kun je je GUI redelijk makkelijk en simpel unittesten.

Ik zie niet in hoe je dit zou kunnen automatiseren.

Je GUI opbouwen vanuit XML is natuurlijk wel een manier om heel zeker van je zaak te zijn dat de GUI geen fouten bevat.

Je kan natuurlijk in de XML ook nog iets fout doen Maar ik bedoel ermee dat ik een gui logica object heb en een gui opbouw object. Het opbouwen wil ik volledig met XML laten plaatsvinden zodat dit makkelijker extern te configureren is (mensen hoeven dan niet meteen de code in te duiken).

[Verwijderd]

Gui (acties ed) bezitten bij meestal wat glue om allerlei non gui objecten aan te sturen. En je loopt sowieso met complexe flow problemen te werken zoals bv aanmaken van een nieuwe iets..

wil je de oude saven? ja nee..
is er iets bij het saven mis gegaan? ja nee..
wil je doorgaan met het beginnen van de nieuwe sessie als er iets mis is gegaan? ja nee... etc etc..

Dit zijn dingen die ik echt niet ga verplaatsen naar objecten die niets met de gui te maken hebben

Die glue waar je het over hebt, is dat niet iets wat er pas bijkomt als je je verschillende packages / tiers / onderdelen gaat samenvoegen (en dus pas gaat testen bij de integratietest?)

Ik zie niet in hoe je dit zou kunnen automatiseren.

Ik ook niet was meer een opmerking , hoe ik dat aanpakte -> unittesten van je GUI.

Maar ik bedoel ermee dat ik een gui logica object heb en een gui opbouw object. Het opbouwen wil ik volledig met XML laten plaatsvinden zodat dit makkelijker extern te configureren is (mensen hoeven dan niet meteen de code in te duiken).

Ik ga er idd even vanuit dat je xml->gui opbouwobject goed werkt en ook goed is ge-unittest . Maar hoe wil je dat GUI logica object dat koppelen aan de gegeneerde GUI? Leg dit ook vast in je XML bestand? Wel relax als je zoiets aan de praat krijgt, scheelt idd veel test werk + je kunt voortaan programmeer n00bs die wel kunnen XML-en, je GUI laten bouwen

[Alarmnummer]

Verwijderd schreef op 21 oktober 2003 @ 11:51:
[...]
Die glue waar je het over hebt, is dat niet iets wat er pas bijkomt als je je verschillende packages / tiers / onderdelen gaat samenvoegen (en dus pas gaat testen bij de integratietest?)

Iedere systeem kan je weer zien als een component als dat systeem als onderdeel wordt gebruikt in een hoger systeem. Het maakt niet uit of iets dan een gui is of een ander object, ik wil het kunnen unit testen. Verder zie ik ook niet veel verschil tussen gui en niet gui (vooral niet als je het een beetje goed opzet).

Ik erger me gewoon aan het feit dat je alles loopt te unit testen, maar dat er enorme test gaten zitten bij de gui. Ik wil dat verschil dus verwijderen.

Ik ga er idd even vanuit dat je xml->gui opbouwobject goed werkt en ook goed is ge-unittest . Maar hoe wil je dat GUI logica object dat koppelen aan de gegeneerde GUI?

Daar zit je idd nog ff mee. Er moet dus een soortement van brug (niet verwarren met Bridge design pattern) komen tussen de gui en de gui logica. Berichten van de gui moeten naar de logica gestuurd worden, en andersom.

Leg dit ook vast in je XML bestand? Wel relax als je zoiets aan de praat krijgt, scheelt idd veel test werk + je kunt voortaan programmeer n00bs die wel kunnen XML-en, je GUI laten bouwen

Het gaat mij erom dat mensen die meer bezig zijn met het visuele gedeelte daar makkelijker wijzigingen in kunnen aanbrengen (ik heb er zelf namelijk een enorme hekel aan). Er zijn al wel een aantal XML oplossingen bv JBeaver, XUL.

[Verwijderd]

Er moet dus een soortement van brug (niet verwarren met Bridge design pattern) komen tussen de gui en de gui logica. Berichten van de gui moeten naar de logica gestuurd worden, en andersom.

FF "for the record" -> Je hebt nu een GUI generatieobject dat een XML fileinleest en daar GUI source-code van genereerd (toch?). Verder heb je een GUI logica object dat door de gegeneerde code gebruikt gaat worden voor het daadwerkelijk uitvoeren van de acties die via de GUI moeten worden ingegeven.

Je weet de interface van het logicaobject toch? Kun je deze interface niet kunnen gebruik in het XML document? Verder zou je toch van alle eventhandlers ook objecten kunnen maken en deze koppelen aan de GUI doormiddel van het XML document?

Weet hier (voor de koppeling) 1, 2, 3... ook niet zo een oplossing voor: ben namelijk ook helemaal geen fan van het maken van GUI, zeker niet als er daarna nog een bulk aanpassingen gemaakt moeten worden.

Persoonlijk zou ik er een boek over designpatterns bij pakken en per pattern ff kijken of die niet een mogelijke oplossing biedt voor de koppeling.

[Alarmnummer]

Verwijderd schreef op 21 October 2003 @ 13:29:
[...]


FF "for the record" -> Je hebt nu een GUI generatieobject dat een XML fileinleest en daar GUI source-code van genereerd (toch?).

De XML varianten die ik ken genereren geen gui java code. Ze bouwen gewoon java gui op aan de hand van een xml beschrijving.

Persoonlijk zou ik er een boek over designpatterns bij pakken en per pattern ff kijken of die niet een mogelijke oplossing biedt voor de koppeling.

Het is niet zozeer een probleem hoe ik het voor elkaar moet krijgen, maar ik wil graag weten hoe en of andere mensen dit probleem ook voor de kiezen hebben gehad en wat voor oplossingen zij bedacht hebben.

Verder is de kans groot dat je een combinatie van patterns moet gebruiken Een enkele pattern is meestal nooit een volledige oplossing.

[ Voor 12% gewijzigd door Alarmnummer op 21-10-2003 13:34 ]

[zoepercavia]

Misschien wel interessant voor de discussie zijn declaratieve user interfaces. Daarbij wordt in het algemeen gewerkt met een xml variant die gerenderd wordt naar een native graphics api. Binnen de XML-variant wordt gewerkt met element behaviours, waarmee de interface interactief wordt (HTML is dit bijvoorbeeld ook).

Op dit moment wordt door meerdere mensen aan dit soort technieken gewerkt:
W3 is bezig de SVG standaard uit te breiden met RCC (Rendering Custom Content), welke dus element behaviours ondersteunt. Onder andere DonXML werkt hier aan (zie bijvoorbeeld zn post hier over een aantal dingen die hij gedaan heeft).
Microsoft is met iets soortgelijks bezig met de nieuwe interface voor LongHorn: Avalon (zie o.a. http://www.eweek.com/article2/0,3959,368868,00.asp). Dit is natuurlijk interessant omdat dit een techniek is die over een aantal jaar door veel developers gebruikt gaat worden.

Om nu aan te sluiten op de discussie. Als je werkt met het renderen naar een tussenlaag (svg, html of je eigen format), moet het in principe mogelijk zijn om je user interface te testen door deze laag te bekijken. Het blijft echter moeilijk om dit netjes te doen omdat je effectief bezig bent xml te parsen en te valideren.
Ik vraag me dan ook af hoe praktisch het is om dit uitgebreid te doen, omdat ik betwijfel of unit tests voor de gui effectiever zijn dan acceptance tests.