public class LazyFilteredCollection extends AbstractLazyCollection {
    @Override
    public String toString() {
        return parentCollection.toString() + " filtered by condition " + condition.toString();
    }
/*
    лучше
    return parentCollection.toString() + " filter(" + condition.getClass().getSimpleName() + ")";

    посмотри на выражение в condition.toString()
    вряд ли нам это надо)

    можно было бы поточнее - отобразить не только имя кондишена , но и ожидаемые значения - т е воспользоваться еще и
    expected()
        но тогда надо менять иерархию

        не AbstractCondition<T> implements Condition<T>, DescribesResult

        а

        AbstractCondition<T> implements Condition<T>
        и
        Condition<T> extends DescribesResult

        цель - чтобы методы интерфейса DescribesResult были доступны для переменной типа
        Condition<T> или его потомков

        это не обязательно делать
*/
**************************
public class LazyFoundByConditionElement extends AbstractLazyElement{
...
    @Override
    public String toString() {
        return parentCollection.toString() + " find by condition " + condition.toString();
    }
/*
    имя класса - подправь согласно той же схеме

    схема = Lazy + откуда + уточнение + Element

    LazyCollectionFoundByConditionElement

    toString() - подправь аналогично описанному выше
*/
**********************************************
/*
  суть в чем
    например, при первом получении getWrappedEntity для
        tasks.find(cssClass("editing")).find(".edit")

    в getWrappedEntity для LazyElementInnerElement
    мы выполняем
    parentElement.getWrappedEntity().findElement(innerLocator)

    а в этот момент
    parentElement.getWrappedEntity() = null

    и мы получается у null пытаемся получить findElement(innerLocator)

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

    вот линка, почитай, достаточно внятная
    http://howtodoinjava.com/core-java/exception-handling/how-to-effectively-handle-nullpointerexception-in-java/

    а потом углуби понимание http://www.yegor256.com/2014/05/13/why-null-is-bad.html
    особенно внимательно на вот этот кусок посмотри http://joxi.ru/5md7jYwtvV5k8r

    получается - что good practice = обходить эти проблемы
    а не перехватывать NullPointerException

    можно конечно поступить так (это первое, что приходит в голову, НО МЫ ТАК ДЕЛАТЬ НЕ БУДЕМ)

        переписывать getWrappedEntity()
            вместо
            return parentElement.getWrappedEntity().findElement(innerLocator);
            пишем
            return parentElement.getWrappedEntity() == null ? null : parentElement.getWrappedEntity().findElement(innerLocator);

        аналогично - и в других классах

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

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

    правило - наш код не возвращает null,
    вместо этого - вызываем исключение (напоминаю про http://joxi.ru/5md7jYwtvV5k8r)

    Дорабатываем наши кондишены
        метод check - у нас уже возвращает значение типа boolean (прошла/не прошла проверка)
        в apply -
            если проверка не прошла - вместо того, чтобы возвращать null -
            вызываем исключение WebDriverAssertionException (отнаследуй от WebDriverException)

            тут, в apply не применяем try-catch

    В WaitFor
        дорабатываем метод until
            как раз тут у нас уже есть try-catch

            получается, что если apply бросит ошибку
            то мы попадем в секцию catch ( в которой эту ошибку просто запомним - в переменную)
            (WebDriverException - мы тут ловим, значит - поймаем и WebDriverAssertionException)

            а если apply не бросит ошибку - значит все ок - проверка прошла
            потому и делаем сразу return condition.apply(lazyEntity)

            итого получили
              в реализация кондишена - мы нуллы нигде не возвращаем (или хорошее значение, или исключение)
              в реализации вейт антила - тоже самое
              причем исключения - используем разные (каждая ситуация = свое исключение)

           следующий момент
             еще один источник null - результат getWrappedEntity() для потомков AbstractLazyElement
             для коллекций такого не будет - с будет просто пустой список
             а вот с элементами - да, будет
             потому - надо чуть доработать код в getWrappedEntity() для классов семейства LazyElement

             применяем ту же логику - мы нуллы нигде не возвращаем (или хорошее значение, или исключение)
                в AbstractLazyElement реализуем getWrappedEntity()
                который вызывает абстрактный метод fetchWrappedEntity() (новый, возвращающий WebElement)
                и если результат fetchWrappedEntity() равен нулл
                то getWrappedEntity() вызовет исключение
                ElementNotFoundException (также отнаследуем от WebDriverException,
                раз у нас уже несколько своих исключений - в core создай для них свой пекедж exceptions)

                а реализация fetchWrappedEntity() - это то, что мы ранее реализовывали в getWrappedEntity()

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

             получили и для getWrappedEntity() - нулла нам теперь этот метод не возвращает
             а это значит - не надо думать про вызовы getWrappedEntity().... - как
             про источник NullPointerExteption

          еще небольшой наворот, раз уж мы так развили работу с исключениями
            в getWrappedEntity() класса LazyCollectionNthElement
            перехватим с помощью try-catch исключение IndexOutOfBoundsException
            и вместо него бросим свое исключение
            LazyСollectionIndexOutOfBoundsException (также отнаследуем от WebDriverException)

            что это нам даст
            в WaitFor.until
            можно ловить только WebDriverException

            т е  - получили более стройную логику

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

          да и то, что мы нигде сами не возвращаем нуллы
          сделало наш код надежнее и проще

          теперь - тесты todoMVC падать не должны)
*/
**********************************************