Migrating from AngularJS to ReactJS or what to do with existing e2e tests
We have a mission critical AngularJS application which we extensively test with e2e tests using Protractor/WebdriverJS. At the current state, we have ~30000 lines of existing e2e tests which are executed daily multiple times either fully or partially for multiple different reasons (e.g. daily or smoke tests).
The application itself is in the beginning stages of "migrating" to ReactJS and the biggest question our QA department is facing is whether we can keep the existing set of e2e tests. As you probably inferred from the size of the test code, we've been investing in e2e tests a lot.
We've been following Page Object pattern and try to keep the page definitions separated from the logic of the tests.
One of the issues that will arise if we try to adopt Protractor test codebase to work against a React-based app is that Protractor would not be able to "sync" with Angular on every selenium command breaking the current natural flow of the e2e tests - I would imagine we would need to put explicit and implicit waits all over the codebase to make sure desired pre-conditions are met before any actions are applied.
What are the pros and cons of adjusting the existing test codebase to work with a ReactJS based application vs starting with e2e tests from scratch with, probably, a better "React-friendly" test framework? What things we should consider to make this decision?
jeanid last edited by
Assumption: I believe we are just talking here on e2e testing of React using protractor.
All UI actions in customized wrapper functions
If we have properly abstracted out all the actions in customized wrapper functions then we can make the global changes less painfully or even change the entire core UI library like selenium to Cypress( if required).
Framework Ignorant Test Scripts, well versed in AUT's DSL
Ideally, test scripts should be framework ignorant as much as possible and should be just well versed in customized DSL of the AUT so that any changes on the framework level could be localized to specific config/settings file.
Locators are always language/framework agnostic anyways
I know it is easier said than done but taking it as a goal while framework design/or refactoring could be worthwhile without taking it too far( YAGNI). Although this is a matter of experience, to know where to draw the line in a given situation as every project is a unique landscape created by the intersection of technology, culture & the domain.
On a different note, I also see current time as an opportunity to correct the fundamental shape of Test Pyramid from cone to pyramid by converting E2E tests into unit tests using React specifics like Mocha & Enzyme.