C React будет тяжело воевать, если нет коммуникации с разработчиками. Много закрытых компонентов, мало уникальных атрибутов.
У нас, к примеру, девелоперы очень сильно упрощали жизнь, добавляя кастомные атрибуты элементам. Для некоторых компонентов даже приходилось пробрасывать backdoor в виде ReactTestUtils
объекта, с помощью которого можно было тригерить различные ивенты для закрытых элементов. С чартами тоже могут быть большие проблемы, если приложение рендерит лишь canvas, без svg.
В общем, если что-то очень простенькое, то, пожалуй, проблем быть не должно. Сложное одностраничное приложение будет тяжело автоматизировать без саппорта.
PageObject с некоторыми оговорками можно все так же использовать. Просто несколько иначе его интерпретировать. У нас, к примеру, приложение было разбито на так называемые сцены, которые можно было создавать / удалять / перетягивать по странице. Исходя из такой постановки, родился SceneObject.
Правда основная проблема с одостраничными приложениями и PageObject концепцией заключается в том, что method chaining невозможно построить, следуя common практикам. Ведь чисто технически, один и тот же DSL метод одной сцены может привести вас на любую другую сцену в рамках одной страницы. Следовательно, мы не можем указать какой-то конкретный тип возвращаемого значения. Тут вам придется подумать о generic механизме перемещения между сценами (компонентами) приложения.
С другой стороны, это неплохая задачка для портфолио в плане презентации Java skills.
Если хотите поиграться на хардкорных компонентах, можете попробовать react-stockcharts. Еще интересный вариант - react-datagrid.