public void doubleClick(WebElement element){
/*
    Получился универсальый метод, который можно применять и в других проектах
    Размести его в классе Helpers как статический метод, в ветке src \ main
    И уже в пейдже - просто используй
*/

****************************

 public SelenideElement startEditing(String oldTaskText, String newTaskText) {
        SelenideElement element = ...;
        doubleClick(element);
        SelenideElement newElement = ....;
        return newElement;
    }
/*
    думаю, было бы не хуже, если тут не использовать промежуточных переменных
    что-то вот такого плана
*/

     public SelenideElement startEditing(String oldTaskText, String newTaskText) {
        doubleClick(...);
        return ...;
    }
**************************
    @Step
    public void delete(String taskText) {
        hover(taskText).$(".destroy").click();
    }

    public SelenideElement hover(String taskText){
        ...
    }
/*
    Можно было не реализовывать hover
    он работает нормально, за тем исплючением, что возвращает null

    было достаточно код в методе delete - разбить на 2 строки
    добавилась бы лишь одна строка кода

    что-то типа такого
*/
    @Step
    public void delete(String taskText) {
        ....hover();
        ....$(".destroy").click();
    }
/*
    где ... - элемент, с которым тут работаем = таска,найденная по ее тексту
    если бы вообще метод hover не работал бі или его не существовало - тогда
    было бы разумнее реализовать hover(...) аналогично doubleClick(...) -
    и в том же классе, и  с такими же параметрами

    а в данном случае - достаточно просто код в методе delete(String taskText)
    разбить на 2 строки - и проще, и достаточно, и понятнее
*/

*********************
название и расположение пекеджа pageоbjects

уже было про это
обычно пекедж для пейджей называют pages (неважно - это пейджи-объекты или пейджи-модули)
и располагают в ветке src \ main

еще раз приведу пример хорошей структуры, примени это для проекта

http://joxi.ru/nAyqEx7HXvxQoA
http://prnt.sc/bvuytd

вот пример хорошей структуры проекта

в src \ main

  core - универсальное, что можно переиспользовать в разных проектах
  pages - пейджи тоже можно переиспользовать для других тестов этого же приложения


в src \ test

  testdata - тестовые данные (если такие есть и они вынесены в отдельный класс)
  testconfigs - предки тест-класса (так можно их изолировать от  собственно тест-классов - чтоб легче было ориентироваться


про пекеджи еще немного)
если GroupID = com.somesite
а проект todomvctest
то пакет корневой должен быть com.somesite.todomvctest

логика  - чтобы "не смешивались имена сущностей"

внутри одной компании - может быть несколько проектов)
и у всех у них один com.somesite  - базовый пекедж
но для каждого проекта должен быть свой  “базовый пекедж проекта"
иначе все смешается)
важно то, что когда этот проект выльется в отдельную библиотеку,
то не будет конфликтов при его подключении