public static void doubleClick(WebElement element){
        Actions action = new Actions(getDriver());
        action.moveToElement(element).doubleClick().perform();
 }
/*
    для даблклика - moveToElement(element) - не нужно делать

    можно кстати реализовать метод actions
    возвращающий new Actions(getDriver())
    может кому-то пригодиться
*/
*************************************
public static List<WebElement> $$(ExpectedCondition<List<WebElement>> conditionToWaitForListFilteredElements)
/*
    не согласна с именем параметра conditionToWaitForListFilteredElements

    это  - просто conditionToWaitForList
    или даже condition - т к тип параметра дает остальные пояснения

    он может быть любым
    главное - чтобы вот такого типа ExpectedCondition<List<WebElement>>
    и чтобы отвечал нашим потребностям
*/
*********************************
/*
    порядок методов в ConciseAPI

    технически - может быть любым

    но чтобы быстрее приходило понимание - разумно применять некую логику и в порядке методов

    от общего к частному
    сначала - ассерты
    потом - $ и $$
    причем - сначала более простые варианты, потом посложнее
    сначала более универсальный вариант, потом - тот, который этот универсальый переиспользует

    рядом друг с другом - методы, возвращающие By

    ну и вначале, конечно
    поле для драйвера + геттер-сеттер

    не настаиваю, но очень рекомендую )
*/
************************
http://joxi.ru/Vrwqg81HKl0xY2
/*
    actualTexts - используется на уровне класса кондишена - в его методах apply & toString
    вот и объяви переменную там
    заодно и не понадобится ее объявлять как final

    actualElements - вообще только в apply используется
    вот в apply и объявляй
    и тоже не понадобится ее объявлять как final

    посмотри - как ты это делала в кондишене sizeOf
    listSize - объявила на уровне класса-кондишена
    elements - внутри apply

    ну и при инициализации этих списков тебе не понадобится addAll
    да и не факт, что будет нужен clear
    для actualElements - так точно не будет нужен

    код станет проще

*/
*******************************
  public static ExpectedCondition<List<WebElement>> exactTextOfVisibleElements(final By elementsLocator, final String... expectedTexts){
/*
    уточни в имени кондишена exactText__s___    -   не поняла как:(
*/
/*

    exactTextOfVisibleElements (сейчас кондишен называется)
    exactTextsOfVisibleElements (вот так я предлагаю изменить)

    буквы одной не хватает
    в прошлый раз выделила ее в комментарии
*/
*********************************
elementWithCssClassAndText
/*
    в этом кондишене, в его apply
    в один обход - собираешь информацию про классы и тексты
    и тут же ее анализируешь
    и найдя элемент - сразу его возвращаешь

    в целом - все ок
    оптимально - не делаем никаких лишних действий

    toString кондишена вызывается в случае - если проверка не прошла
    значит - на момент вызова toString - все списки будут собраны

    если конечно по пути не возникнет какого-то исключения)
    это первое если)

    а второй момент
    toString любого класса - это способ приведения объекта к строке
    и было бы логично - при проектировании toString
    не думать про то - когда мы его вызываем
    а думать про корректное описание объекта
    вне зависимости от обстоятельств

    из этих соображений - разумнее собрать классы и тексты - в списки заранее
    getTexts - уже есть такой метод для сбора текстов
    реализуй и getClasses - и тожеего используй
    и уже после того - как списки собраны - анализируй их

    согласна - мы проиграем в скорости
    не думаю, что прямо катастрофически
    зато код будет проще и корректнее
    ну и надежнее тоже

*/
***********************************
if (isElementHasCssClass(element, cssClass)){
   if (element.getText().equals(exactText)) {
/*
    можно вместо вложенных if-ов использовать оператор &&

    погугли про него
*/
***************************
elementWithText
/*
    то же самое и тут
    используй getTexts
    а потом уже енализируй собранный список текстов
*/
*****************************
public static Boolean isElementHasCssClass(WebElement element, String expectedClass){
        String[] classes = element.getAttribute("class").split(" ");
        for (String classAtr : classes) {
            if (classAtr.equals(expectedClass)){
                return true;
            }
        }
        return false;
}
/*
    вообще-то нам нужем метод
    который в уже ранее полученной строке - значении атрибута class - classAttribute
    ищет cssClass

    и реализовать можно лаконичнее
    return Arrays.asList(classAttribute.split(" ")).contains(cssClass)

    чтоб понять - почему так можно
    надо почитать про contains для списка
*/
*************************
http://joxi.ru/V2VBQLqf0gOjk2
/*
    все же некорректно держать это в пекедже google

    думаю, больше порядка будет если перенести все на уровень выше
    или переименовать пекедж google
*/
************************************
http://joxi.ru/EA4k7zEUDJYP82
/*
    и в этой ветке тоже
    странно держать тесты в пекедже google
    ведь мы не работаем в google,
    и не все продукты, что мы тестируем - относятся к google

    грамотнее - на уровень выше
    или переименовать пекедж google

    ниже  - напишу про структуру подробнее
*/
*******************
http://joxi.ru/YmEnRaLFZ4V5d2
/*
    пейджи для разных проектов должны быть на одном уровне иерархии
    что-то мудрено пока )

    а с учетом того - что у нас есть еще и гивен-хелперы
    то может правильнее вот такую структуру сделать

    core
        ...
    todomvc
        givenhelpers
        pages
    gmail
        pages
*/
******************************
 ((JavascriptExecutor) getDriver()).executeScript(jsCode.concat("]\")"));
 getDriver().navigate().refresh();
/*
    оба метода стоит реализовать в ConciseAPI

    executeJavaScript
    refresh
*/
*********************************
hover(assertThat(elementWithText(tasks, taskText)));
or
hover($(elementWithText(tasks, taskText)));
/*
    второй вариант - технически - то же самое
    но - точнее описывает что мы делаем

    мы получаем элемент через ожидание elementWithText
    чтобы далее выполнить над ним действие

    $ - применяем - когда работаем с элементом
    assertThat - применяем - когда речь именно о проверке

    реализуй такой вариант $
*/
*******************************************
 doubleClick(assertThat(elementWithText(tasks, oldTaskText)).findElement(By.tagName("label")));
 или
 doubleClick($(elementWithText(tasks, oldTaskText),"label"));
 /*
    для второго варианта - все есть
 */
**********************************************
public void edit(String oldTaskText, String newTaskText) {
public void cancelEdit(String oldTaskText, String newTaskText) {
/*
    и тут можно реализовать startEdit
    только теперь возвращай WebElment

    и далее - или энтер, или эскейп останется послать
*/

************************************
http://joxi.ru/nAyqEx7HXvxQoA

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

в src \ main

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


в src \ test

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


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

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

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