Testen van front end project (Node/Gulp)

[egonolieux]

Dag tweakers,

Ik ben een Bootstrap/jQuery plugin aan het bouwen om afbeeldingen te previewen voordat ze geupload worden naar de server. Ik maak ondertussen van de gelegenheid gebruik om Node.js/npm en Gulp onder de knie te krijgen maar heb hier enkele vragen over waar ik tot op heden geen duidelijk antwoord op kon vinden.

Ik ben op de hoogte van testframeworks zoals Mocha, maar hoe kan ik het project makkelijk als geheel testen? M.a.w., hoe kan ik de applicatie draaien in de browser zonder een apart test project te maken en mijn plugin daar te installeren? Mijn naieve oplossing zou gewoonweg een index.html maken zijn, maar als ik naar andere projecten kijk zoals Bootstrap, vind ik deze manier van werken niet terug.

Het probleem met het installeren in een ander testproject is dat ik BrowserSync niet kan gebruiken en ik telkens manueel de browser weer moet refreshen.

Wat is hier de gebruikelijke manier van werken die ik mis?

[Spinal]

Als ik het goed heb is Mocha meer voor unittests, maar waar jij naar op zoek bent is Selenium WebDriver
Daarmee kun je tests schrijven die zeggen "Klik op de link met titel 'Afbeelding uploaden', vul bestandsnaam 'foobar.jpg' in, klik op 'Uploaden'"

Wij gebruiken het hier in combinatie met Protractor, maar iets vergelijkbaars bestaat ongetwijfeld ook voor niet-Angular-projecten.

[egonolieux]

Selenium lijkt me inderdaad zeer handig om "functioneel" testen te automatiseren, maar mijn vraag heeft voornamelijk betrekking tot manueel testen.

Ik kan me moeilijk voorstellen dat een project gepublished wordt zonder deze manueel eens te testen.
Ik heb het hier dan voornamelijk over projecten als jQuery plugins waar geen HTML in de source zit.

Om deze dan toch manueel te testen lijkt me de meest voor de hand liggende oplossing gewoonweg een index.html maken zodat er in combinatie met BrowserSync makkelijk manueel getest kan worden.

Het feit dat ik deze manier van werken niet kan terugvinden, doet me vermoeden dat er een andere manier van werken bestaat.

[Ventieldopje]

egonolieux schreef op maandag 29 augustus 2016 @ 16:20:
Selenium lijkt me inderdaad zeer handig om "functioneel" testen te automatiseren, maar mijn vraag heeft voornamelijk betrekking tot manueel testen.

Ik kan me moeilijk voorstellen dat een project gepublished wordt zonder deze manueel eens te testen.
Ik heb het hier dan voornamelijk over projecten als jQuery plugins waar geen HTML in de source zit.

Om deze dan toch manueel te testen lijkt me de meest voor de hand liggende oplossing gewoonweg een index.html maken zodat er in combinatie met BrowserSync makkelijk manueel getest kan worden.

Het feit dat ik deze manier van werken niet kan terugvinden, doet me vermoeden dat er een andere manier van werken bestaat.

Waarom manueel testen? Dan heb je altijd een onvoorspelbare factor, die nog eens veel tijd kost ook.

Het is veel beter om goede unit tests te schrijven zodat je betrouwbare resultaten krijgt. Je kan dat met Selenium of met PhantomJS doen bijvoorbeeld.

[egonolieux]

Ventieldopje schreef op maandag 29 augustus 2016 @ 16:24:
[...]


Waarom manueel testen? Dan heb je altijd een onvoorspelbare factor, die nog eens veel tijd kost ook.

Het is veel beter om goede unit tests te schrijven zodat je betrouwbare resultaten krijgt. Je kan dat met Selenium of met PhantomJS doen bijvoorbeeld.

Ik had het misschien beter moeten verwoorden.

De Bootstrap/jQuery plugin die ik aan het schrijven ben, gedraagt zich als een Bootstrap JS component, zoals een modal bvb. Ik zit dus met zowel HTML, JS en CSS en zou dit dus manueel willen "testen" als ik aan de CSS aan het werken ben. Dit is zeer makkelijk te doen door gewoonweg de index.html te starten met Gulp/BrowserSync.

Als ik echter naar de Github repository van Bootstrap en dergelijke kijk, zie ik echter nergens een index.html. Aangezien ik me niet kan voorstellen dat ze hun CSS nooit visueel testen, doet me dat vermoeden dat er een andere manier van werken is waar ik niet van af weet.

[Ventieldopje]

egonolieux schreef op maandag 29 augustus 2016 @ 17:11:
[...]


Ik had het misschien beter moeten verwoorden.

De Bootstrap/jQuery plugin die ik aan het schrijven ben, gedraagt zich als een Bootstrap JS component, zoals een modal bvb. Ik zit dus met zowel HTML, JS en CSS en zou dit dus manueel willen "testen" als ik aan de CSS aan het werken ben. Dit is zeer makkelijk te doen door gewoonweg de index.html te starten met Gulp/BrowserSync.

Als ik echter naar de Github repository van Bootstrap en dergelijke kijk, zie ik echter nergens een index.html. Aangezien ik me niet kan voorstellen dat ze hun CSS nooit visueel testen, doet me dat vermoeden dat er een andere manier van werken is waar ik niet van af weet.

Je kunt toch ook handmatig gewoon een html bestand maken met het component dat je wil testen? Je zou dit zelfs als snippet in je IDE kunnen gebruiken.

Wat let je om een gulp task te schrijven die zo'n bestand uitpoept?

[egonolieux]

Ventieldopje schreef op maandag 29 augustus 2016 @ 17:42:
[...]


Je kunt toch ook handmatig gewoon een html bestand maken met het component dat je wil testen? Je zou dit zelfs als snippet in je IDE kunnen gebruiken.

Wat let je om een gulp task te schrijven die zo'n bestand uitpoept?

Dat is wat ik momenteel doe, maar ik vind het raar dat andere repositories het index bestand niet in version control opnemen. Dan moet je telkens bij het clonen opnieuw manueel de index aanmaken (tenzij met gulp).

[Ventieldopje]

egonolieux schreef op maandag 29 augustus 2016 @ 18:29:
[...]


Dat is wat ik momenteel doe, maar ik vind het raar dat andere repositories het index bestand niet in version control opnemen. Dan moet je telkens bij het clonen opnieuw manueel de index aanmaken (tenzij met gulp).

Dat kun je toch gewoon zien in hun grunt/gulp files? Maar maak daar een ticket aan zou ik zeggen. Als jij dat vermoeden hebt zullen zij jou dat kunnen vertellen hoe hun het doen.

Imho is het nogal developer afhankelijk en wil je daarom niet je repository vervuilen met dat soort code die A. niet voor gebruikers van belang is en B. niet voor de unit tests van belang is.

[Ossebol]

Waarom trap je met Gulp de browser runner Karma niet af, waarmee je tests in een testframework runt? Dat kan Mocha zijn, maar ik raad je in dit geval QUnit aan. Dat framework komt uit de jQuery-stal en wordt daar dus al voor gebruikt.

[egonolieux]

Ossebol schreef op vrijdag 09 september 2016 @ 22:01:
Waarom trap je met Gulp de browser runner Karma niet af, waarmee je tests in een testframework runt? Dat kan Mocha zijn, maar ik raad je in dit geval QUnit aan. Dat framework komt uit de jQuery-stal en wordt daar dus al voor gebruikt.

Voor dit project gebruik ik eigenlijk geen unit tests (te klein en eenvoudig), maar Karma valt zeker te overwegen bij toekomstige projecten.

Mijn probleem was van in het begin eigenlijk reeds opgelost door gewoon een index te gebruiken, maar aangezien ik bij andere projecten deze manier van werken niet direct kon terugvinden, stelde ik me de vraag of anderen iets wisten waar ik niet op de hoogte van was.