Vergelijking
Testmode versus Selenium
Selenium is de al lang bestaande open standaard voor browserautomatisering. Testmode beschrijft tests in gewone taal. Zo verschillen ze, en wanneer welke de juiste keuze is.
Kort antwoord: Selenium is de juiste keuze wanneer je brede taal- en browserondersteuning nodig hebt, volledige controle, en geen leverancier in de keten. Testmode is de juiste keuze wanneer het onderhouden van een Selenium-suite een klus is geworden die niemand wil.
Selenium is de oudste en meest uitgerolde browserautomatiseringstool ter wereld. WebDriver, het protocol eronder, is een W3C-standaard die browsers rechtstreeks implementeren. Het gaat nergens heen.
In één oogopslag
| Selenium | Testmode | |
|---|---|---|
| Tests schrijven | Java, Python, C#, Ruby, JavaScript | Gewone taal |
| Wie tests kan schrijven | Ontwikkelaars | Iedereen die de workflow begrijpt |
| Wat je out of the box krijgt | Alleen browserbesturing | Schrijven, draaien en rapporteren |
| Testrunner en asserties | Zelf meebrengen | Inbegrepen |
| Onderhoud bij UI-wijzigingen | Selectors worden met de hand bijgewerkt | De AI interpreteert de beschreven bedoeling opnieuw |
| Schalen | Selenium Grid, zelf gehost of bij een cloudaanbieder | Beheerd |
| Kostenmodel | Gratis en open source, plus ontwikkeltijd | Commercieel product |
Waar Selenium de betere tool is
- Je hebt een andere taal dan JavaScript nodig. De taalondersteuning van Selenium is ongeëvenaard. Voor een Java- of C#-huis beslecht dat vaak de vraag.
- Je moet browsers testen die niets anders bereikt. Omdat WebDriver een standaard is die de browsers zelf implementeren, is de dekking breder dan die van welke individuele leverancier ook.
- Je wilt geen afhankelijkheid van een commercieel product. Selenium is gratis, open source en wordt bestuurd door een stichting.
- Je hebt al een suite en de engineers om die te draaien. Een werkende Selenium-suite is een bezit. Gooi er geen weg voor de nieuwigheid.
Het deel dat teams onderschatten
Selenium geeft je browserbesturing en verder niets. Een werkende testsuite heeft ook een testrunner nodig, een assertiebibliotheek, rapportage, parallellisatie en een wachtstrategie. Die stel je zelf samen.
De wachtstrategie is waar de meeste Selenium-suites misgaan. WebDriver probeert vrolijk op een element te klikken dat nog niet is gerenderd, dus schrijven teams expliciete waits, en daarna nog meer expliciete waits, en houden een suite over die met tussenpozen faalt om redenen die niets met de geteste software te maken hebben. Wispelturigheid is de meest voorkomende reden dat teams een Selenium-suite niet meer vertrouwen, en zodra dat vertrouwen weg is, wordt de suite genegeerd in plaats van gerepareerd.
Testmode wacht zoals een mens dat doet — het kijkt naar de pagina en handelt wanneer het benodigde er werkelijk is.
Waar Testmode beter past
- Niemand wil de suite bewaken. Selenium-suites worden vaak geërfd, en degene die het framework schreef is meestal vertrokken.
- Tests schrijven is een knelpunt. Elke nieuwe flow heeft een ontwikkelaar nodig. Testmode verplaatst het schrijven naar de mensen die de eisen kennen.
- Je suite is wispelturig en niemand vertrouwt hem. Betekenen storingen niets meer, dan doet de suite haar werk niet.
- Je hebt de software niet zelf gebouwd. Page objects schrijven tegen de markup van een leverancier is duur en breekt bij hun volgende release.
De eerlijke samenvatting
Selenium wint op reikwijdte, controle en prijs. Het is het juiste antwoord voor teams met de ontwikkelcapaciteit om het goed te draaien.
Testmode wint wanneer die capaciteit precies is wat je niet hebt. Rot je Selenium-suite langzaam weg omdat het onderhoud niemands prioriteit is, dan lost een ander framework dat niet op — het werk weghalen bij engineering wel.
Nog aan het vergelijken? Alternatieven voor Selenium behandelt het bredere veld. Of bekijk alle vergelijkingen.