public class LazyCollectionFiltered extends AbstractLazyCollection {
/*
    см прошлое ревью
    строки 3-20
*/
**********************
public class LazyCollectionFiltered extends AbstractLazyCollection {

    private LazyCollection parentCollection;
    private Condition<WebElement> condition;

...
    @Override
    public String toString() {
        return parentCollection.toString() ;
    }
/*
    у нас есть - родительская коллекция + операция = фильтрация + как фильтруем = такой-то кондишен
    это все должно быть отражено в toString()

        return parentCollection.toString() + " filter(" + condition.getClass().getSimpleName() + ")";

    а почему я не советовала использовать condition.toString() - ты мне расскажи)

    аналогично - и для LazyCollectionFoundByConditionElement поправь
*/
******************************************
public class Enabled extends ElementCondition {

 ...
    @Override
    protected boolean check(WebElement element) {
        isEnabled = element.isDisplayed();
/*
    см прошлое ревью
    строки 124-127
*/
********************************************
tasks.filter(visible()).shouldHave(exactTexts(taskTexts));
/*
    раз мы уже так умеем - то как считаешь - нужны нам такие кондишены?
        ExactTextsOfVisible
        SizeOfVisible
*/
*********************************
public class CssClass extends ElementCondition {
    ...
    @Override
    protected boolean check(WebElement element) {
        actualClass = element.getAttribute("class");
        String[] classes = actualClass.split(" ");
        return classes.equals(expectedClass);
    /*
        читаем код

        мы сравниваем массив строк со строкой

        как думаешь - что в результате такого сравнения получим?
        вспомни - как похожий кондишен реализовывали раньше
    */
***************************************
    public class Configuration {
        //default interval for WaitFor.Until - smart waiting check one condition, in milliseconds
        public static int timeout = 4000;
    /*
        замечаем - таймаут храним в миллисекундах
    */

   public <T> T until(Condition<T> condition, long timeOutInSeconds) {
   ...
        while (System.currentTimeMillis() - startTime < timeOutInSeconds * 1000);
    /*
        тут - оперируем таймаутом в секундах
    */

    public <T> T until(Condition<T>... conditions) {
        ...
                result = until(condition, Configuration.timeout);
    /*
        но - не смотря на это - передаем в метод миллисекунды ...

        как думаешь - что в итоге получим?

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

        ты в слеке писала - про зависание
        это не оно
        это ожидание выполнения кондишена в 4000 * 1000 миллисекунд)

        осваивай отладку)
        очень полезный навык
        вот видео
        https://drive.google.com/file/d/0B2UFaKOpHq_MUEtTUDFoZzdTbTg/view?usp=sharing
        это такой... еще черновик
        но там - все верно показано, и все вот такие штуки - учись применять
        наверняка про это можно кучу других материалов найти...
        минимально - будет достаточно освоить показанное
    */
****************************************
        @Override
        public WebElement getWrappedEntity() {
            ...
                throw new ElementNotFoundException();
                /*
                    можно что-то и написать в качестве сообщения об ошибке)
                    например - передав в конструктор ElementNotFoundException как параметр -
                    тот же toString() самого лейзи элемента
                */
***********************************************
http://joxi.ru/p275M9zs0eZagr

/*
    давай разберем - что за NPE еще есть

    1-кликни на упавшем тесте
    2-кликни в стектрейсе на Visible
    3-увидишь на какой строке тест упал

    если тут возникло NPE - значит именно isDisplayed - в этот момент равен null
    можно его инициализировать значением false - еще при объявлении(4)

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

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

    мы искусственнно добавим ожиданий

    и код наших ждущих проверок под отладкой - будет работать не так
    как он работает в режиме обычного запуска
    потому - будем встраивать отладочные сообщения
        в метод iterator() для коллекции  - перед циклом
        System.out.println("Building iterator..."+toString());

        в метод fetchWrappedEntity() класса LazyCollectionFoundByConditionElement
        перед циклом System.out.println(toString()+"get wrapped entity");
        внутри цикла System.out.println("   check "+condition.getClass().getSimpleName()+ " for element..."+element.getWrappedEntity().getText());


    разберем на примере теста testEditAtActive()

    получим такие сообщения
*/

By.cssSelector: #todo-list>li find(ExactText)get wrapped entity
Building iterator...By.cssSelector: #todo-list>li
   check ExactText for element...a
By.cssSelector: #todo-list>li find(ExactText)get wrapped entity
Building iterator...By.cssSelector: #todo-list>li
   check ExactText for element...a
By.cssSelector: #todo-list>li find(ExactText)get wrapped entity
Building iterator...By.cssSelector: #todo-list>li
   check ExactText for element...a
...

/*
    т е далее вызова apply - для первого элемента - дело не идет...
    как думаешь - почему?

    давай посмотрим на реализацию apply

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

    кстати - тогда бессмысленно проверять результат apply - на равенство null ...

    какие наши варианты
      в методе fetchWrappedEntity() класса LazyCollectionFoundByConditionElement -
      можно обернуть вызов apply - в try-catch секцию
      и ловить это исключение
      так себе метод - здорово утяжелит код

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

      пока он нам не доступен... - мы не можем вызвать метод check кондишена
      т к у интерфейса кондишена такой метод не объявлен.

      поступим пока не красиво - объявим на уровне интерфейса Condition - метод check
      тогда для метода check - придется поправить во всех реализованных кондишенах - модификатор доступа -
      protected на public

      про красоту  - чуть позже побеспокоимся )
      сейчас про функциональность

      раз у нас будет метод check объявлен на уровне интерфейса - значит мы сможем его использовать
      в варианте condition.check(...)

      только заметь - в качестве параметра для check - надо уже не лейзи-сущность передавать
      а то, что возвращает getWrappedEntity....

      получим - нормальную картинку - тест проходит
      отдалочные сообщения - показывают - что мы продвигаемся по списку -
      а не вылетаем из цикла на первой же итерации, на которой условие не выполнилось
*/
By.cssSelector: #todo-list>li find(ExactText)get wrapped entity
Building iterator...By.cssSelector: #todo-list>li
   check ExactText for element...a
   check ExactText for element...b
By.cssSelector: #todo-list>li find(ExactText)get wrapped entity
Building iterator...By.cssSelector: #todo-list>li
   check ExactText for element...a
   check ExactText for element...b

/*
    в результате - в методе fetchWrappedEntity() класса LazyCollectionFoundByConditionElement
    будет вот такой код
*/

        for (LazyElement element : parentCollection) {
            WebElement wrappedElement = element.getWrappedEntity();
            if (condition.check(wrappedElement)) {
                return wrappedElement;
            }
        }
        throw new ElementNotFoundException(this.toString());
/*
    и что по факту мы делаем

        сначала - заворачиваем каждый вебэлемент списка коллекции (чтобы воспользоваться итератом для нашей коллекции)
        а потом - на каждом шаге - разворачиваем (получаем wrappedElement = element.getWrappedEntity())

        т е - делаем таки кучу не нужной работы
        хоть код и красивый, конечно...

    правильнее - для оптимизации реально выполняемых действий - отказаться от идеи обхода коллекции таким образом
        for (LazyElement element : parentCollection)

    а реализовать вот так
        получить список вебэлементов parentCollection.getWrappedEntity()
        обойти полученный список вебэлементов в цикле
        и применять к вебэлементу - метод check

        сэкономим на заворачиваниях-разворачиваниях)

    поправь методы fetchWrappedEntity()
         и для LazyCollectionFoundByConditionElement
         и для LazyCollectionFiltered

    убедись - что все тесты в проекте работают

    красоту с check - наведем после следующего ревью...

*/