Migrating from AngularJS to ReactJS or what to do with existing e2e tests

Question

The Story

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.

The Question

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?

Answer 1

Assumption: I believe we are just talking here on e2e testing of React using protractor.

Generalized JavaScript Framework agnostic to any Frontend frameworks

IMHO, in such cases we should strive to generalize the framework on JavaScript level taking advantage of latest ESx features(like async/await for promise resolution) .The framework should be agnostic to any specific frontend framework considering we might need to migrate few more times in future from React to some next latest & greatest frameworks as well.

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

As far as page objects are concerned, they could be designed purely on JavaScript level. Also, locators are 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.