/*
    переходи уже на селениум 2.53.1 )
    с фф 46.0.1 все ок работает
*/
***********************************
public class Configuration {
    public static long timeout = 15;
}
/*
    по умолчанию оставляй 4 секунды (не зря в Selenide именно такое значение - как правило - его хватает)
    заметь - тут - в отличие от Selenide - меряем в секундах

    посмотри на описание параметров конструктора WebDriverWait
    new WebDriverWait(getWebDriver(), timeout)
    зажав секд наведи курсор мыши на WebDriverWait и почитай во всплывающей подсказке
    что за сигнатура у конструктора
    увидишь - что ждем число секунд
*/
***************************************
    @BeforeClass
    public static void timeout() {
        Configuration.timeout = 20000;
    }
/*
    потому и тут - тоже должны быть секунды
    20 секунд достаточно)
*/
********************************************
/*
    в прошлом ревью писала тебе - строки 141-150

    убивай класс ByText
    и просто возвращай
    By.xpath(".//*/text()[normalize-space(.) = " + Quotes.escape(elementText) + "]/parent::*");

    если приведенная выше метаморфоза - не понятна - спроси
    фактически - вынесла преобразование из ByText

    тут никаких профитов от класса ByText - не будет
*/
*********************************************
public static By byTitle(String title)
/*
    тут интереснее)
    да, ты верно перенесла код из selenide)

    код из byAttribute (а именно этот код мы и вызываем в byTitle)
    подразумевает проверку атрибута на равенство

    http://joxi.ru/YmEnRaLFZR6BQ2
    у меня к примеру - 88 непрочитанных писем)
    и текст атрибута - не Inbox, а Inbox(88)

    странно, что раньше это не вылезло)
    как вариант - в Selenide мы проскакивали мимо такой ошибки
    из-за того что в инбоксе были все письма прочитанные?

    предлагаю
        переименовать метод byAttribute - в byAttributeExactText (именно это он и делает)

        реализовать метод byAttributeText - который будет искать текст по вхождению в значение атрибута
        полезный материал по xpath
        https://drive.google.com/file/d/0B2UFaKOpHq_MdXF4OUhPODVETUU/view?usp=sharing
        вот этот вариант тебе нужен - http://joxi.ru/vAW36KgskdElbA
        отладь этот xpath в FireFinder или FirePath

    а после этого реализовать
        byTitle  - по вхождению (используя byAttributeText)
        byExactTitle - по равенству (используя byAttributeExactText)

    и вот  - тебе - подойдет именно byTitle  - в такой реализации (когда по вхождению в title ищется элемент)

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

    вариант 1
        на этот вопрос - можно получить ответ в отладке)
        http://joxi.ru/E2pdR1lFB3exM2

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

        а потом - сходили и сами посмотрели - что это за зверь
        http://joxi.ru/krDOZldF0D537A

    вариант 2
         что у тебя находится по byText - кстати тоже можно проверить
         http://joxi.ru/Q2KpJYOs9BaWXA (тут, кстати FirePath оказался лучшим инструментом)

    нам точно нужны не они)
    так что - по title будеи искать)

    то же касается и других вариантов, фактически сводящихся к определению элемента по xPath
    берешь xPath выражение из метода и отлаживаешься
*/
**************************************************
 public void switchToInbox() {
 ...
        assertThat(urlMatches("https://mail.google.com/mail/u/0/#inbox"));
 }
/*
    эта проверка уже не нужна)
    ты проконтролировала переход на Inbox

    прибивай ее
*/

**************************************************

public class BaseTest extends ConciseAPI {

 ....
    public WebDriverWait wait = new WebDriverWait(driver, 4);
 ....
/*
    вот это - уже не нужно
    т к у тебя есть assertThat - этой переменной wait уже не пользуешься
    убивай)
*/
********************************************************
http://joxi.ru/eAO7pYkt4BndgA
/*
    для порядку перенеси пекедж pages в src/main
*/
****************************************************
public class GmailTest extends BaseTest {

    String subject = "my new mail " + new Date().toString();
    /*
        эта переменная - нужна только для тест-метода testLoginSendAndSearchMail()
        фактически - это тестовые данные для метода testLoginSendAndSearchMail()
        и ничто не предвещает - что это в других тест-методах этого класса
        будет востребовано
        потому - перенеси объявление и инициализацию переменной внутрь метода testLoginSendAndSearchMail()
    */
...
    @Test
    public void testLoginSendAndSearchMail() {

        GmailPage page = new GmailPage(driver);
    /*
        А вот с page - ситуация обратная
        page - может пригодиться и в других тест-методах класса
        это инструмент для тест-класса, а не конкретного тест-метода

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

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

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

    public void assertMail(String text) {
        listNthElementHasText(mails, 0, text);
    }

    public void assertMails(String... texts) {
        textsOf(mails, texts);
    }
/*
    еще раз почитай в прошлом ревью строки 262 - 292

    вместо
        listNthElementHasText(mails, 0, text)
    нам нужен
        assertThat(listNthElementHasText(mails, 0, text))

    вместо
        textsOf(mails, texts)
    нам нужен
        assertThat(textsOf(mails, texts))

    т к - мы делаем проверки, а не просто хотим получить значение типа ExpectedCondition

    значение типа ExpectedCondition - это по сути - правило - как проверить, но не сама проверка

    сама проверка = new WebDriverWait(...).until(condition) = assertThat(condition)
        new WebDriverWait(...).until = assertThat = что сделать
        condition - как именно сделать

    мы тут просто получили - как нам это сделать
    а делать - не стали)

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

http://joxi.ru/p275M9zs0wp6Kr

/*
    красивая ошибка)

    1 - если то-то
    2 - то делать - тото (делать - точку с запятой)
    3 - это в любом случае уже делаем

    не зря в стандартах гугла - фигурные скобки предписано использовать в обязательном порядке
    https://google.github.io/styleguide/javaguide.html#s4.1.1-braces-always-used

    это еще не все)
    пока не проверяй)
*/
***************************************
http://joxi.ru/Vrwqg81HK6dYR2

/*
    1 - давай применим elementExceptionsCatcher
    цель - избавиться от try-catch в самом apply

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

    кстати - обрати внимание - как ты уже тут ловила несколько видов исключений в одной catch-секции
    так можно и в кетчере это сделать)

    Ты задала очень правильный вопрос в слеке
    если return elements.get(index); - список же может опять переискаться? и вылезет что-то другое... ((
    ага... может)

    как выкручиваемся
        2 - сохраняем актуальный текст нужного нам элемента в этой переменной
        3 - сначала получаем сам элемент (он уже не переискивается - он не лейзи прокси)
        4 - у него получаем текст
        5 - сверяем полученный текст
        6 - возвращаем элемент из пункта 3 (не заново ищем в списке, а возвращаем тот же, по которому делали выводы)
        7 - в тексте ошибки оперируем только актуальным текстом, который мы получили в пункте 4 (заново не получаем)

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

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

    выводы
        8 - возвращаем ровно тот же элемент, текст которого проверяли
        9 - описываем проверенный в apply текст
*/
****************************************************************

http://joxi.ru/bmoWZzahMJ0q4m

/*
    кетчер у нас теперь вот такой
    1 - упростили параметр (помнишь - для вейт антила упрощали, тут - то же самое)
    2 - одна catch-секция
*/
*****************************************************************
http://joxi.ru/ZrJX8Y3f14Zoz2
/*
    1-2-3 - этот кондишен делаем как ExpectedCondition<List<WebElement>>

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

    5 - actualTexts - всегда инициализируем вначале apply
    причина - каждый вызов  apply - проверка заново
    надооперировать свежими данными

    6 - у нас ExpectedCondition<List<WebElement>>
    когда проверка прошла - в случае успеха мы возвращаем тот же лейзи-прокси список

    7 - когда проверка не прошла - возвращаем нулл

    8 - в toString() - используем тот же список текстов, что сохранили в actualTexts
    apply - когда принимали решение - проверка прошла или нет
*/
************************************************
/*
    надеюсь, многое прояснилось)

    следующее задание - ты фактически его же реализовала

    в нем мы добавим - избавимся от лейзи прокси
        это значит
            кондишены - оперируют локатором By
            при создании пейджа - не надо  PageFactory.initElements

    т е  - по большому счету - поработаещь плотненько с кондишенами)

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