@Override
    public boolean is(Condition<WebElement> condition) {
        try {
            return condition.check(getWrappedEntity());
        } catch (WebDriverException ex) {
            throw new ElementNotFoundException(this.toString());
        }
    }
/*
    В даном случае - мы отвечаем на вопрос - выполняется кондишен или нет -  да/нет

    и даже если мы словили эксепшен - не надо бросать новый
    это значит - нет, кондишен не выполняется
    не важно, какая причина
    нас тут не о том спрашивали)

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

    тут - мы просто отвечаем на вопрос - выполняется кондишен или нет
    мы ничего не ждем и повторно не проверяем
    но и рассчитываем только на да/нет
*/
*****************
public class CssClass extends AbstractCondition<WebElement> {

    public Boolean actualState;
   ...
   /*
        эта переменная уже не нужна
   */


    @Override
    public boolean check(WebElement element) {
        ...
        actualState = isElementHasCssClass(actualClass, expectedClass);
        return actualState;
        /*
            тут можно проще - return isElementHasCssClass(actualClass, expectedClass);
        */
    }

*****************************************************************************
public class ExactTexts extends Texts {
/*
    за счет наследования от Texts - тут можно реализовать лишь метод check
    на тот же MinimumSize посмотри)

    еще момент
    списки строк на равенство можно сверить в одну строку - actualTexts.equals(expectedTexts);
    http://www.java2s.com/Tutorial/Java/0140__Collections/CheckingforEquality.htm
*/
***********************************************
    public class WithWaitFor<V> {

    ...

        public V run(final Command<V> command){
/*
    реализаци класса - ок
    и его использование  - тоже

    можно чуть изменить - не на уровне класса объявлять дженерик-класс <V>
    а на уровне метода run
    ведь только  в это методе мы оперируем командой типа Command<V>
    и только в этом методе - получаем результат типа <V>

    тогда сможешь при вызовах писать
    не return new WithWaitFor<String>(this, visible()).run(new Command<String>() ....
    а  return new WithWaitFor(this, visible()).run(new Command<String>() ....

    а если еще в WithWaitFor - реализуешь статический метод withWaitFor
    то return withWaitFor(this, visible()).run(new Command<String>() ....

    вот это поправь

    и еще
    если мы оперируем дженерик-типом, объявленным на уровне метода и используемым как тип возвращаемого значения - используй <V>
    а если оперируем дженерик-типом, обхявленным на уровне класса - используй <T>

     http://stackoverflow.com/questions/6008241/java-generics-e-and-t-what-is-the-difference

        когда типизируешь generic-типом класс - то T (T is meant to be a Type)

        а когда речь идет о типизации значения, возвращаемого методом -  V (V is Value (as a return value or mapped value))

        т е - тут = T is meant to be a Type

        а вот в   public <V> V run(Command<V> command) - как раз V правильно
        т к V - это тип возвращаемого значения

     тут, после изменений - будем работать с методом
     public <V> V run(final Command<V> command)
      и дженерик-типа на уровне класса - объявлять не будем
     а раз так - то тут -  используем <V>

     а вот для Command - грамотнее оперировать <T>

     просмотри весь код на этот предмет
*/
*******************************
public String getTagName() {
/*
    тут достаточно ждать present()
*/
************************
public boolean isSelected() {
/*
    а тут лучше ждать видимости
    только для видимых элементов это важно - isSelected()
*/
******************************
public class ElementNotFoundException extends WebDriverException {
    public ElementNotFoundException() {
}
/*
    Мы не используем конструкторы эксепшенов без параметров

    предлагаю такие конструкторы удалить)

    касается всех реализованных эксепшенов
*/

*****************************
public abstract class Load<T, V> {
/*
    класс можно убирать из проекта
*/
******************************
LazyCollection tasks = $("#todo-list").findAll("li");
/*
    в конечной версии - используй $$("#todo-list>li");

    проверили findAll - и ок )

*/
*****************************
    private void toggle(String taskClass, String taskText) {
        $$(taskClass).find(text(taskText)).$(".toggle").click();
    }
/*
    реализация в твоей селенидовской работе - была лучше
    т к мы отталкивались от tasks - были точнее и однозначнее
    предлагаю и тут также реализовать

    и придется подправить вызовы в
    complete и activate
*/
    private void toggle(String taskClass, String taskText){
        tasks.filterBy(cssClass(taskClass)).findBy(exactText(taskText)).$(".toggle").click();
    }
********************************
    public void edit(String oldTaskText, String newTaskText) {
    public void cancelEdit(String oldTaskText, String newTaskText) {
/*
    в этих методах - нам не нужно sendKeys(newTaskText + ...);

    только вызвать - pressEnter()  / pressEscape()
*/
********************************
tasks.shouldHave(size(0));
/*
    полезно реализовать кондишен empty()
    c реализацией size(0)

    и использовать его в пейдже
*/
**********************************************
    public static <V> V assertThat(ExpectedCondition<V> condition) {
        return (new WebDriverWait(getDriver(), Configuration.timeout)).until(condition);
    }
/*
    WebDriverWait - принимает таймаут в секундах

    у нас - таймаут в миллисекундах

    передавай таймаут, пересчитанный в секунды
*/
************************************
/*
    еще момент
    у меня например - это проявлялось
    скорее всего - у тебя тоже
    тесты для todoMVC - нестабильно работают

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

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

    хорошо от этого помогает если в гивен-методе после refresh();
    сверить размер коллекции с количеством переданных тасок
    $$("#todo-list>li").shouldHave(size(tasks.lengt));
    фактически - такая проверка выполняет роль ожидания - что страница готова к работе

    если б гивены жили в том же пейдже - вообще красиво бы получилось
    а так  - в GivenHelpers придется вот такой код вставить
    не DRY получается

    я сейчас работаю над материалом - как такие вещи ждать более универсально
    надеюсь на неделе отдать
    пока предлагаю - вставить вот такую не DRY проверку
    а я потороплюсь)

    по итогу - уже чистим проект окончательно
    убедись  - что все работает
    что нет ничего лишнего
    лишних рабочих каких-то комментариев
    форматирование, пропуски ...
    ну и чтоб тесты бегали)
*/