public class GmailMain {
/*
    Вынести вспомогательные методы и переменные в пейдж - правильная идея

    и разумно - что реализовала именно пейдж-модуль
    меньше лишнего кода)

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

    для пейджей - лучше используй пекедж pages

    а насчет имени пейджа-модуля - ниже будет больше предложений)
*/
*************************************************
    public static String login = ...
    public static String password = ...
/*
    вот это важный момент
    не стоит смешивать тестовые даные и пейджи

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

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

    более того
    при правильной структуре проекта
    пейджи расположены в src \ main \ ...
    а тестовые данные - в src \ test \ ...

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

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

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

    Вынеси эти данные в отдельный класс - как публичные статические поля
    и используй их в тест-методе - в качестве значений параметров для тест-методов
*/
**********************
        $("[aria-label='To']").setValue(login);
        /*
            по-моему, там name - тоже красивый)
        */
        ...
        $(withText("Your message has been sent.")).shouldBe(visible);
        /*
            этой проверки делать не нужно
            после отправки письма - лучше принулительно обновить состояние аккаунта

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

                        перед проверкой - что письмо пришло
                        хорошо выполнить действие - принудительно получить почту = обновить -
                        нажать на кнопку - http://joxi.ru/V2VBQLqf05vL92

            но - этот рефреш правильнее реализовывать как отдельный метод
        */
******************************************
    public static void sentFolder(){
        $("[role='navigation']").find(withText("Sent")).click();
    }
/*
    имя метода = что делать
    ниже предложу варианты

    насчет методов класса By
    тут - не стоит использовать import static
    мы не так много экономим на By.
    да и по только названию многих из этих методов не всегда можно быстро понять - о чем речь
    уточнение By. - бывает важным

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

    public static void assertMailExist(String topic){
        $$(byText(topic)).filter(visible).shouldHaveSize(1);
    }
/*
    тут можно и поточнее, и пошустрее проверку использовать)

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

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

    потому - можно использовать более однозначную проверку
    что в списке у элемента с индексом ... текст содержит ...

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

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

    не факт - что найдем именно мейл из списка мейлов)
    лучше оттолкнуться именно от коллекции мейлов

    заметь - в данном случае - мы не уточняемся конкретно до колонки с topic
    значит - и параметр метода - не стоит так называть ...
*/
*************************************************
    public static void searchMailAndAssertUnique(String topic){
        $("[aria-label='Search']").setValue(topic).pressEnter();
        $$(byText(topic)).filter(visible).shouldHaveSize(1);
    }
/*
    писала тебе в прошлый раз)

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

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

    насчет имени параметра метода - тоже - это не topic)
    может мы и передаем topic
    но в контексте этого метода - это queryText )

    для cтроки поиска - подойдет вариант - как и для google search
    используй тот вариант)
*/
******************************
public class GmailMainTest {
/*
   Main - не добавляет никаких сведений полезых )
   я бы сократила до GmailTest
*/
...
    @Test
    public void testSendAndSearch(){
    /*
        тестируем login, send, receive and search )
        можно все и перечислить)
    */
        open("https://mail.google.com");

        login();

        send("My New Topic");
        /*
            давай запустим тест дважды подряд
            в ящике будет 2 письма с одинаковым топиком
            и тест должен будет упасть на последней проверке

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

        /*
            дальше мы должны сделать согласно задания

            check that mail arrived

            это значит - надо проверить -
            что самое верхнее письмо во входящих - наше

            а перед этим - надо принудительно обновить почту
            http://joxi.ru/V2VBQLqf05vL92

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

        */

        sentFolder();
        assertMailExist("My New Topic");

        searchMailAndAssertUnique("My New Topic");
        /*
            search the arrived mail by topic
            значит - перед поиском надо вернуться в папку входящие
        */
    }
***********************************************
/*

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

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

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

                    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  - базовый пекедж
    но для каждого проекта должен быть свой  “базовый пекедж проекта"
    иначе все смешается)
    важно то, что когда этот проект выльется в отдельную библиотеку,
    то не будет конфликтов при его подключении

*/