public By byCss(String cssSelector) {
     return By.cssSelector(cssSelector);
 }

 public By by(String cssSelector) {
     return byCss(cssSelector);
 }
/*
    зачем тебе 2 метода с одинаковой функциональостью?

    byCss - более точное имя, его и используй

    метод - by(String cssSelector) - удали
*/
*************************************************************

    public By ById(String cssSelector) {
        return ById(cssSelector);
    }
/*
    сомневаюсь, что используешь это метод)
    да и вопрос, нужен ли подобный метод, ведь можно так написать byCss("#id") вместо ByID("id")
    не менее понятно)

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

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

   public <V> V assertThat(Function<? super WebDriver, V> condition) {
/*
    реализация верная, можно чуть упростить - использовать параметр типа ExpectedCondition<V> condition
    вместо Function<? super WebDriver, V> condition
    про это - ниже поямню подробнее

    реализуй также вариант
    public static <V> V assertThat(ExpectedCondition<V> condition, WebDriver driver, int timeout)
    с такой же функциональностью - но таймаут  - передаем как параметр
    такой вариант  - более универсальный и позволяет для какого-то единственного тормозящего элемента -
    выполнить проверку с таймаутом, который отличается от Configuration.timeout

    а как реализуешь вариант
    public static <V> V assertThat(ExpectedCondition<V> condition, WebDriver driver, int timeout)
    используй в public <V> V assertThat(Function<? super WebDriver, V> condition)
    вызов этого  более универсального метода - получишь DRY код
*/

    /*
        можно было бы реализовать метод assertThat с параметрами попроще -
            public static <V> V assertThat(ExpectedCondition<V> condition, WebDriver driver, int timeout)
        а не
            public static <V> V assertThat(Function<? super WebDriver, V> condition, WebDriver driver, int timeout)

        если зажав ctrl кликнешь на until - то увидишь его реализацию и сигнатуру
        а сингатура - public <V> V until(Function<? super T, V> isTrue)
        т е - наш кондишен типа ExpectedCondition<V> может быть приведен в типу Function<? super T, V> (edited)
        а если точно также зажав ctrl кликнуть на ExpectedCondition - то увидишь
    */
    /**
     * Models a condition that might reasonably be expected to eventually evaluate to something that is
     * neither null nor false. Examples would include determining if a web page has loaded or that an
     * element is visible.
     * <p>
     * Note that it is expected that ExpectedConditions are idempotent. They will be called in a loop by
     * the {@link WebDriverWait} and any modification of the state of the application under test may
     * have unexpected side-effects.
     *
     * @param <T> The return type
     */
    public interface ExpectedCondition<T> extends Function<WebDriver, T> {}

    /*
        т е - мы можем выполнить такое приведение типов - т к это предок для ExpectedCondition
        (это довольно грубое пояснение, но пока достаточное, чтоб не лезть в дебри -
        на самом деле Function - это интерфейс, который имплементирован в классе ExpectedConditions,
        про интерфейсы поговорим, но позже и подробнее))

        можешь и чуть далее углубиться - на Function кликнуть с ctrl
        это интерфейс, объявленный в com.google.common.base;
    */
    /**
     * Determines an output value based on an input value.
     *
     * <p>The {@link Functions} class provides common functions and related utilites.
     *
     * <p>See the Guava User Guide article on <a href=
     * "https://github.com/google/guava/wiki/FunctionalExplained">the use of {@code
     * Function}</a>.
     *
     * @author Kevin Bourrillion
     * @since 2.0
     */
    @GwtCompatible
    public interface Function<F, T> {
    /*
        Сейчас - пока достаточно общего поинмания - что есть что
        а в assertThat - можно упростить сигнатуру до  -
            public static <V> V assertThat(ExpectedCondition<V> condition, WebDriver driver, int timeout)
        это - надо хорошо понимать
        ну и про предка ExpectedCondition - что он Function.... (посмотри - из какого пекеджа)
        пока  - этого понимания будет достаточно
    */

********************************************************************************************************
http://joxi.ru/krDOZldF0Db9NA

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

    но - core - это не привязанные к какому-то тестируемому приложению инструменты
    полностью универсальные

    pages - униварсальные в рамках тестов определенного приложения
*/
******************************************
public class Base extends ConciseAPI {

/*
    реализация пейджа-предка = ок
    и она  - как раз универсальная = не привязанный к какому-то тестируемому приложению инструмент
    перенеси этот класс в core

    а теперь вспомни
    какие отличия в нейминге классов - для пейджей-объектов и пейджей-модулей
    и поправь имена классов пейджей и их предка)
*/
********************************************************
$(By.id("Email"))

/*
    ага, избегаешь метод ById использовать)))
    права)

    сравни
    $(By.id("Email"))
    vs
    $("#Email")
    мне кажется - второй вариант куда приятнее)
*/
*********************************************

    public void searchMails(String text) {
        $(By.id("gbqfq")).sendKeys(text, Keys.ENTER);
    }
/*
    ты понагляднее вариант для локатора этого поля использовала в селенидовской версии
    загляни туда
*/
***********************************************
/*
    ок, пока делаем версию с лейзи-прокси элементами

    и у нас первая задача - реализовать проверку, аналогичную селенидовской
*/
    public static void assertMails(String... mailTexts) {
        mails.shouldHave(texts(mailTexts));
    }
/*
    Мы использовали кондишен для коллекции элементов - texts

    в селениуме - такого кондишена нету
    и мы его напишем и разместим в CustomConditions

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

    давай сначала разберемся с типом кондишена, который будем реализовывать
    можно реализовать ExpectedCondition<Boolean>
    тогда в случае успеха - assertThat - вернет True
    в случае не успеха - тест упадет (как ему и положено)
    а метод apply кондишена - будет возвращать
    True - если проверка пройдена
    False - если она не пройдена

    мы можем больше пользы извлечь из ситуации, если такой кондишен будет типа
    ExpectedCondition<List<WebElement>>
    тогда в случае успеха - assertThat вернет List<WebElement>
    и можно будет писать что-то такое - assertThat(sizeOf(elementsList,10)).get(9).click();
    (это если кондишен sizeOf был бы реализован с первым параметром - List<WebElement>)
    а метод apply кондишена - будет возвращать
        List<WebElement> - тот же лейзи прокси список, который получил на входе - если проверка пройдена
        null - если она не пройдена

    так
    с типом кондишена определились
    нужен кондишен ExpectedCondition<List<WebElement>>

    теперь с параметрами
    проверяем  - лейзи прокси список веб элементов - List<WebElement> elements
    что проверяем у этого списка - текстЫ = String... expectedTexts

    Загляни в  селениумский класс ExpectedConditions
    (в коде - зажав ctrl + кликнув на имя любого стандартного селениумского кондишена)
    там можно почерпнуть ряд идей

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

    т е задача номер один = зафиксировать = ЭТО состояние
    используй список строк для того, чтобы сохранить в нем тексты всех элементов ашего лейзи-прокси списка

    получили список актуальных текстов

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

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

     вспомни - зачем реализовывали метод toString у кондишена
         когда проверка не проходит - эта информация выводится в описании ошибки
         потому - тут мы должны описать - и актуальное (ЭТО состоняние - которое мы зафиксировали в списке строк)
         и ожидаемое состояние (переданные в кондишен ожидаемые тексты)

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

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

/*
    есть еще одна проверка, которую хорошо бы реализовать
    чтобы избавиться от
     @FindBy(css = "[role = 'main'] .zA:nth-child(1)")
        public WebElement firstMail;

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

    то у нас получилась бы - удобная универсальная проверка
*/
    public void assertMail(int index, String mailText) {
        assertThat(nthElementHasText(mails, index, mailText));
    }
/*
    следующая цель - реализовать кондишен nthElementHasText
    и удаление уже ненужного лейзи прокси firstMail

    если разберешься с кондишеном texts - попробуй реализовать и этот

    будет сложно с texts - отложи этот кусок
    реализуем позже
    как все вопросы по texts решим
*/