public static <V> V waitUntil(By locator, Condition<V> condition, long timeoutMs)  {
 /*
    молодец - что все таймауты в миллисекундах
    уже и название параметров для таймаута поправь

    только тут timeoutMs
    в остальных местах - используешь timeout
    при этом  - везде четко используешь значение в миллисекундах

    советую поправить тут - на timeout
    а в Configuration - написать комментарии
 */
       ...
            } catch (StaleElementReferenceException | ElementNotVisibleException
                    | IndexOutOfBoundsException | NoSuchElementException e) {
/*
    посмотри на предков всех перечисленных исключений (зажать ctrl плюс кликнуть на имени класса,
    возможно - так несколько раз)
    у всех, кроме  IndexOutOfBoundsException - предком является WebDriverException

    можешь ловить лишь IndexOutOfBoundsException и WebDriverException - будет не хуже )
*/
...

        throw new TimeoutException(String.format("Locator ['%s'], timeout ['%s'] sec, Condition ['%s'] " +
                " Error is ['%s']",locator.toString(), timeoutMs/1000, condition.toString(), lastError), lastError);
/*
        failed while waiting ... seconds
        to assert __condition___

         __condition___ - это как раз toString кондишена
         остальное полезное и умное - напишем там
*/
*****************************************************

/*
    хорошая идея - реализовать умное ожидание в отдельном классе
    с точки зрения Single Responsibility - так будет лучше

    наглядно этот класс назвать WaitFor
    а статический метод-умный ожидатель выполнения кондишена - until
    и в коде мы будем писать waitFor(byCss(...)).until(visible())
    получится очень наглядная и понятная фраза

    в том же классе - расположи и метод sleep
    а его сделай - private
    т к sleep будет нужен только для реализации ждущей проверки

    чтобы так писать - waitFor(byCss(...)).until(visible())
        реализуй конструктор с параметром By locator

        реализуй статический метод waitFor с параметром By locator
        возвращающий - новый объект класса WaitFor

        реализуй метод until(...)
    получишь
       waitFor(byCss(...)). - создали объект типа WaitFor
          until(visible()) - вызвали у него метод until

    конечно, until-у передаай как кондишен, так и таймаут
    уже второй вариант  until-а - без таймаута (также как и раньше - такой берет таймаут по умолчанию
*/
*********************************************
/*
    Иерархия для кондишенов у тебя сейчас - достаточно простая

    интерфейс
    и классы-кондишены, имплементирующие его

    Минимально необходимая реализация есть

    Будем ее развивать

    Далее - реализуй абстрактный класс-предок AbstractCondition<V> ,
    который имплементирует интерфейс Condition<V>

    Статья про нейминг
    http://www.vertigrated.com/blog/2011/02/interface-and-class-naming-anti-patterns-java-naming-convention-tautologies/

    Теперь смотрим дальше
    Нам хочется, чтобы наш toString() для любого кондишена был хорошо структурирован
    Это значит, чтобы фразы были типа

          __имя кондишена__ +
          for ____element/elements___ found by: ___locator___
          expected ___expected result description_____
          actual ____actual result description_____

    Можно конечно в каждом из кондишенов просто строить такую фразу
    согласно правилу

    А можно - toString() реализовать в абстрактном классе, и внутри этого метода - вызывать абстрактные методы
    а их уже - реализуем в потомках. Таким образом - структура сообщения любого из кондишенов
    будет одинаковой

    где брать ___locator___ тут - мы чуть позже поговорим...
    пока пропусти этот момент

    а вто для
        ____element/elements___
        ___expected result description_____
        ____actual result description____
    объяви и используй абстрактные методы
        identity()
        expected()
        actual()

    __имя кондишена__
    раз мы будем реализовывать кондишены как отдельные классы - потомки (пока - нашего абстрактного класса)
    то откуда взять имя кондишена - у нас есть
    у нас есть имя класса кондишена - чем не имя )

    Далее
    element/elements
    Это только верхушечка айсберга
    Да, схема проверки кондишенов - у нас одна и та же
    Хоть это кондишен для списка элементов
    Хоть для элемента
    И нам нужно, чтоб наш waitUntil был один и работал с любым кондишеном

    Но
    Нам важна разница - что это за кондишен - для элемента или коллекции
    В данный момент - чтобы сказать про то в фразе - for ____element/elements
    А далее (в следующих заданиях) - чтобы кондишены для element - мы просто  НЕ МОГЛИ применить к elements
    Таким образом, приходим к тому, что у нашего общего предка AbstractCondition<V>
    Будут 2 абстрактных потомка
        CollectionCondition extends AbstractCondition<List<WebElement>>
        ElementCondition extends AbstractCondition<WebElement>
    От которых мы будем наследовать наши реальные кондишены

    И тогда, стоит держать 2 класса для реализации статических методов - вызовов кондишенов
    CollectionConditions и  ElementConditions
        это будут классы-контейнеры статических методов
        типа
        public static Condition<WebElement> visible() {
            return new Visible();
        }
        чтобы уже в коде  - не писать - new Visible()

    С иерархией разобрались немного )

    Возвращаемся к фразе в toString()
        Если этот метод реализовать в главном предке AbstractCondition,
        и этот метод будет использовать абстрактные методы, возвращающие строки
        для всех элементов этой фразы
        То структура сообщения о кондишене - будет всегда четкой

    А нам останется - реализовать эти абстрактные методы, возвращающие строки
    в потомках
    Тут смотри внимательно
    Некоторые из методов надо будет реализовать уже в кондишенах-потомках
    Некоторые - в CollectionCondition и ElementCondition

    Руководствуйся такими рассуждениями
    Если во всех потомках я пишу одинаковый код
    То лучше этот код написать в предке

    Что касается типа параметра condition для
    until(Condition<V> condition)

    Ты можешь указать интерфейс Condition<V>

    И метод будет корректно работать для любого из кондишенов
    Т к этот интерфейс лежит в основе этой иерархии
*/
***************************************************
/*
    еще один наворот внутри кондишенов)

    мы его впоследствии переделаем

    сейчас нам это нужно для лучшего понимания процесса

    в apply передают локатор
    описание которого мы возвращаем в одном из методов кондишена (для ToString)
    и это - справедливо для всех кондишенов

    и нам - еще в AbstractCondition интересно сохранить этот локатор

    потому в AbstractCondition заводим переменную locator
    и реализуем метод apply
    в котором
        сохраняем переданный в apply локатор
        и вызываем абстрактный метод check
        (- который, собственно, и нужно будет в кондишенах реализовывать вместо apply)

    check - будет делать то же, что и  apply делал ранее
    нам  это нужно было для того, чтоб локатор получить еще на уровне абстрактного класса

    теперь - и в toString - мы можем подправить фразу - про локатор

    сразу подумай, какой модификатор доступа использовать для такой переменной
    http://www.quizful.net/interview/java/access-modifiers

    но это опять была только верхушка айсберга)

    посмотри на реализованные кондишены
    первой строкой в методе проверок - у тебя идет
    List<WebElement> elements = getDriver().findElements(elementsLocator);
    или
    WebElement element = getDriver().findElement(elementsLocator);
    (таких, кстати, пока нету
        реализуй
        visible
        present
        text
        exactText
    )

    Так вот
    фактически - вот это
    List<WebElement> elements = getDriver().findElements(elementsLocator);
    или
    WebElement element = getDriver().findElement(elementsLocator);

    это сущность типа V с точки зрения класса AbstractCondition

    давай метод check изменим
    пусть принимает не локатор
    а уже V entity (т е внутри кондишена в реализации check
    нам ничего не придется искать по локатору - нам это уже на вход передадут)

    а вот в реализации apply в AbstractCondition
    для получения этого V entity
    мы объявим новый абстрактный метод getWrappedEntity()
    который будет нам возвращать значение типа V

    а реализуем его в классах CollectionCondition и ElementCondition

    думаю, ты догадаешься, как )

    а вот потом, когда у нас будут наши классы для элементов (следующее задание)
    мы будем в apply передавать не локатор
    а сам элемент нашего нового класса
    и сам элемент будет возвращать getWrappedEntity()
    и мы тут, в кондишенах, избавимся от  getWrappedEntity() и его реализаций )

    пока это такой костыль
    нарушающий принцип Single Responsibility
    но позволяющий нам сейчас максимально реализовать код
    который впоследствии изменим минимально
*/