/*
    Запускала твой тест
    гугл что-то заподозрил))
    просит подтвердить личность)))
    зайди в свой тестовый аккаунт вручную, успокой его
*/

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

/*
    ага, красиво )

    см какой таймаут установлен для gmail теста = 45

    45 чего?
    миллисекунд)
    вот и ответ)

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

    кстати, для параметра assertThat ты так и поступила)

    думаю - стоит и в других местах подправить

    собственно - этого достаточно, чтобы тест работал
*/
******************************
Вопрос, почему для кондишенов мы выбрали <V>? Вроде там тоже параметризуется тип.

/*
    да, все верно
    и для кондишенов стоит подправить)
*/
************************************
В иерархии классов/интерфейсов для кондишенов я решила оставить, как есть.
Поскольку, действительно, “добавляемые в вариант 1 интерфейсы CollectionCondition & ElementCondition -
      не используются как интерфейсы, от которых имплементированы классы
”, ну и по всем тем ссылкам, которые ты дала почиать, часто говориться,
что, мол делай   те с умом, чтобы было удобно и не перегружать структуру излишними элементами,
которые не будут реально использоваться.

/*

    ну, да)
    можно

    только -  подумай еще вот над этим
*/

public class CollectionConditions {

    public static Condition<List<WebElement>> sizeOf(int expectedSize)
    ....

или

public class CollectionConditions {

    public static  CollectionCondition sizeOf(int expectedSize)
    ....


и вот тут

public interface LazyCollection extends LazyEntity<List<WebElement>>, Iterable<LazyElement> {
    List<WebElement> shouldHave(Condition<List<WebElement>> condition);

или

public interface LazyCollection extends LazyEntity<List<WebElement>>, Iterable<LazyElement> {
    List<WebElement> shouldHave(CollectionCondition condition);

/*
    техически - ты, конечно, права,
    использовав тип интерфейса Condition<List<WebElement>>
    а не абстрактрого класса  CollectionCondition
    для типов параметров и возвращаемых значений

    но - согласись - кон гораздо проще чиатется
    если использовать CollectionCondition )

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

    но и не говорил - что это единственно верный вариант)

    мне сначала показалось точнее - как ты реализовала )
    а вотом  - захотелось внешней красоты (красоты со стороны человека,который фреймворк будет использовать)
    и я таки добавила интерфейсы CollectionCondition и ElementCondition
    а абстрактные классы назвала  Abstract....
    Ну и в качестве типов параметров и возвращаемых значений -
    использовала интерфейсы CollectionCondition и ElementCondition

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

    ты можешь и свой вариант оставить


*/
******************************

а еще лучше - объявляй в интерфейсе и имплементируй метод с параметром Condition<List<WebElement>>... conditions
Это на будущее? Или это уже сейчас надо где-то использовать? (мы делали аналогичный метод until в WaitFor)

/*
    да, ты права, мы уже это слелали в until в WaitFor

    и реализуя такой should - нам достаточно вызвать уже реализованный с такими параметрами until в WaitFor

    тут  - уже не нало заново циклов и прочего
    достаточно просто вызвать until в WaitFor - с правильными параметрами)

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


    реализовав should, который оперирует сразу перечнем кондишенов
     мы сможем его вызвать - указывая как один кондишен, так и несколько
     т е - достаточно метода
          LazyElement should(ElementCondition... conditions);
     а варианта
          LazyElement should(ElementCondition condition); - уже и не понадобится

     это касается всех should-методов

     также - можно реализовать несколько should-методов (по аналогии с селениде)
     с немного отличающимися именами - чтоб код читался как нормальные фразы англ языка
     should / shouldBe / shouldHave
*/
***************************************************************

@Override
public WebElement shouldBe(Condition<WebElement> condition) {
   return waitFor(this).until(condition);
}

Здесь надо так написать, или вот так:

@Override
public WebElement shouldBe(Condition<WebElement> condition) {
   return waitFor(this).until(visible(), condition);
}

/*
    однозначно - первый вариант

    когда мы вызываем should - мы сами в состоянии диктовать
    какие проверки выполнить и в какой последовательности
    (мы же реализуем параметр метода как Condition<WebElement>... conditions)
*/
*********************************************

    @Override
    public Iterator<LazyElement> iterator() {
        List<LazyElement> list = null;
        for (WebElement element: getWrappedEntity()) {
            list.add(new LazyWrappedWebElement(element));
        }
        return list.iterator();
    }
/*
    Да, тип возвращаешь верный)
    сама реализация - верная

    за исключением первой строчки
    List<LazyElement> list = null;

    тебе нужно инициализировать список
    List<LazyElement> list = new ArrayList<>();

    как проверить - что метод рабочий - напиши тест-метод, типа такого(использую уже тудуэмвиси приложение):
*/
    @Test
    public void testIterator() {
        givenAtAll(ACTIVE, "аb", "ааb", "ac", "bc");

        for (LazyElement element:tasks) {
            System.out.println(element.getText());
        }
    }
/*
    не сказать - что это прямо полноценный тест

    можешь точно также - для gmail
    перебрать в такого же рода цикле все мейлы и вывести их тексты

    если цикл типа for (LazyElement element:elements)  - работает
    значит - метод iterator ты правильно реализовала
*/
*************************************************
public interface LazyElement extends LazyEntity<WebElement>, WebElement {

/*
    помимо выше описанного по should-ам
    объяви тут и реализуй в абстрактном классе
*/
LazyElement pressEscape();
*********************************************
public interface LazyCollection extends LazyEntity<List<WebElement>>, Iterable<LazyElement> {
/*
    помимо выше описанного по should-ам
    объяви тут и реализуй в абстрактном классе

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

    int size();

    boolean isEmpty();

    String[] getTexts();
**********************************************************

    @Override
    public LazyElement doubleClick() {
        return null;
    }

    @Override
    public LazyElement hover() {
        return null;
    }

/*
    вспомни свою работу - когда понижади версию Selenide  до 2.17
    и реализовывали doubleClick() )
    https://github.com/ljubanka/todomvctest/blob/oldselenide/src/main/java/ua/net/itlabs/Helpers.java

    осталось разобраться - откуда взять actions()
    это не сложно)

    hover - схема аналогичная
*/
***********************************************************
    public LazyElement setValue(String text) {
        ...
        element.sendKeys(text + Keys.ENTER);
        ...
    }
/*
   setValue = очистили поле и ввели текст
   нажатие энтера сюда не входит
*/
**************************************

    public Point getLocation() {
    public Dimension getSize() {
    public Rectangle getRect() {
/*
    тут лучше видимости ждать - речь про видимое расположение элемента
*/
********************************************

    public void sendKeys(CharSequence... var1) {
        ...
        element.clear();
        ...
/*
    не надо тут clear()

    делаем только то, что обещали
    обещали - sendKeys
*/
*******************************************
    public LazyElement pressEnter() {
 /*
    тут можно переиспользовать уже реализованный sendKeys (метод этого же класса)
    будет лаконичнее
 */
******************************************

public class LazyWrappedWebElement extends AbstractLazyElement{

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

    ну и в toString - выводила бы что-то типа
    "WebElement " + element.toString() + " from " + parentEntity

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

public static LazyWebDriverElement $(By locator){
        return new LazyWebDriverElement(locator);//waitFor(locator).until(visible());
}

/*
    вот этот момент еще надо понять

    да, объект мы создаем - как LazyWebDriverElement
    но - в качестве типа возвращаемого значения = используем интерфейс LazyElement

    объект, имплементирующий такой интерфейс, спокойно приводится к типу интерфейса

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

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

        именно поэтому SelenideElement - это интерфейс

        и List - тоже интерфейс
        и мы используем
            List<String> myListOfStrings = new ArrayList<String>()
        а не
            ArrayList<String> myListOfStrings = new ArrayList<String>()

     то же касается и коллекции
*/
**************************************

public static By emails = byCSS("[role='main'] .zA");
/*
    это уже можно объявлять как LazyCollection и инициализировать как $$("[role='main'] .zA")
    должно работать))
*/