public void openUrl() {
        open("https://www.google.com/gmail/about/");
    }
/*
    если воспользоваться урлом  http://gmail.com
    некоторые действия делать просто не придется)
*/
*****************************

    SelenideElement signIn = $(".gmail-nav__nav-links-wrap>a:nth-child(2)");
 ...

    public void signIn() {
        signIn.click();
    ...
/*
    вот это действие - signIn.click()
    делать бы не пришлось - если использовать урл gmail-а

    но - и для такого способа - для элемента signIn
    можно найти селектор полаконичнее и понагляднее
    например = [data-g-label='Sign in']
    а может быть - прошел бы и такой вариант - $(By.linkText("Sign in"))

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

*/
***************************************
    String email = "[email protected]";
    String password = "123Ballamy";
/*
    это - тестовые данные

    пейдж и тестовые даные не должны ничего знать друг о друге

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

    к примеру - для метода  пейджа signIn(...)
    нам нужны параметры метода - String login, String password
    тогда - ты для своего теста - при вызове метода пейджа - передашь свои логин-пароль
    а я - свои

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

    для тестовых данных - логина и пароля
    организуй свой класс - TestData, Credentials ...

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

    как расположить классы - позже распишу
*/
********************************
    public void sendTestLetter(){
    /*
        метод можно назвать и полаконичнее - send

        а вот параметров - ему надо бы добавить)

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

            единственное - запустив тест дважды - получим проблему
            мы с темой "Sended Test Message" - уже 2 письма найдем)

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

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

            не надо зашивать внутри метода - тему письма
        */
        $(".vh").shouldHave(exactText("Your message has been sent. View message"));
        /*
            вот этого - ждать не нужно

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

            а во-вторых - чтобы гарантировать - что во входящих мы увидим письмо -
            лучше всего после отправки письма - выполнить рефреш - принудительно получить письма
            собственно - метод для этого у тебя есть ) - refresh()
            и с ним все ок)

            этого - достаточного таймаута и выполнения рефреша - вполне достаточно
        */
    }
***************************
    public void assertEmailPresent(int index, String emailSubject){
            $$("[role='main'] .zA").get(index).shouldHave(text(emailSubject));
    }
/*
    будет понятно - если метод назвать лаконичнее assertEmail или assertMail

    mail vs email - это надо будет определиться - чтоб один термин употреблять)


    что касается второго параметра String emailSubject
    судя по реализованной проверке - мы не четко Subject проверяем
    это - ок
    но - лучше - чтобы имя параметра точно описывало это
    mailText, mailHeaderText - будет уместнее

    сама реализация  - ок

    $$("[role='main'] .zA") - вот это - список мейлов
    он может и для других целей пригодиться
    стоит вынести в переменную пейджа
*/
*****************************
src / test / java / gmail / features /

/*
    не надо располагать тест-класс в features

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

    подними пока тест-метод на уровень вверх
*/
***********************************

public class GoogleEmailTest extends GoogleEmail {
/*
    неожиданно)

    не надо наследовать тест-класс - от пейджа
    практика плохая

    повспоминай вот эти материалы
    http://joxi.ru/nAyqEx7HXJZBMA

    в данной работе - пейджи-модули были бы удобным решением (ниже напишу подробнее)

    имя тест-класса - GmailTest - было бы ок
    четко описывает - что тестим

    кстати, ты видел? - здорово расширился faq по неймингу
    https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.zfcd0angknhf
*/

    @Test
    public void basicEmailLifeCycle() {
    /*
        можно так

        а можно и перечислить - что тестим

        testSignInSendReceiveAndSearch - не очень длинно)
    */
        openUrl();

        signIn();

        sendTestLetter();
        refresh();

        assertEmailPresent(0, "Sended Test Message");

        switchToSent();
        assertEmailPresent(0, "Sended Test Message");

        /*
            это не все, что нужно сделать)

            осталось - search the arrived mail by topic and ensure only 1 is present in search results
            а это значит - надо вернуться в папку Входящие
            с помощью строки поиска - найти по теме письма
            и убедиться - что найдено 1 письмо, причем наше
        */
    }
}
*****************************************************************

/*
    Тут это, конечно, немного за уши притянуто
                Просто попробуем разделить функционал на несколько пейджей, чтоб понять,
                как это использовать и как оформлять код, когда используем несколько пейджей

                Ниже приведу код, когда используется несколько пейдж модулей
                обрати внимание на
                    названия самих методов

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

                        Gmail.vizit();

                        Gmail.logIn(TestData.email, TestData.password);

                        Mails.send(TestData.email, subject);

                        Menu.refresh();
                        Mails.assertMail(0,subject);

                        Menu.goToSent();
                        Mails.assertMail(0,subject);

                        Menu.goToInbox();
                        Mails.searchBySubject(subject);

                        Mails.assertMails(subject);
*/

/*
    http://joxi.ru/nAyqEx7HXvxQoA

    вот пример хорошей структуры проекта

    в src \ main

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


    в src \ test

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


    про пекеджи еще немного)
    если GroupID = com.somesite
    а проект todomvctest
    то пакет корневой должен быть com.somesite.todomvctest

    логика  - чтобы "не смешивались имена сущностей"

    внутри одной компании - может быть несколько проектов)
    и у всех у них один com.somesite  - базовый пекедж
    но для каждого проекта должен быть свой  “базовый пекедж проекта"
    иначе все смешается)
    важно то, что когда этот проект выльется в отдельную библиотеку,
    то не будет конфликтов при его подключении
*/