public class GmailSendAndSearchTaskTest {
/*
    С именем тест- класса - перебор)

    GmailTest - достаточно
    Task - точно ни при чем

    просмотри в faq раздел по неймингу
*/
    {
        Configuration.browser = "firefox";
        /*
            firefox - и так по умолчанию запустится
            єто не нужно уточнять
        */
        Configuration.timeout = 20000;
    }
*****************************************
    public static String generateUniqueString(String subject){
/*
        да, ты передаешь текст subject-а
        это так

        но когда ты объявляешь и реализуешь метод
        названия должны точно отражать НЕ контекст вызова
        а ДЕТАЛИ  РЕАЛИЗАЦИИ

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

        с точки зрения реализации метода - параметр = префикст для UniqueString
*/
************************************************
public class Mails {

    public static ElementsCollection mails = ...;
    /*
        да, это идеальный селектор

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

**********************
    public static void search(String subject){
/*
    и для поля поиска в gmail - такой же селектор как для такого же поля в google search
    посмотри и сравни

    про имя параметра - то же самое

    если бы ты реализовала метод
    используя текст запроса - subject:....

    а если такая реализация как у тебя - параметр = просто текст запроса
    не обязательно это должен быть subject
*/
*******************************************
    public static void assertMail(int index, String subject){
/*
    это уже не надо - System.out.println
*/
*************************************************
    public static void assertMail(String subject){
/*
    CollectionCondition.texts - применила верно
    советую посмотреть на реализацию этого кондишена

    посмотри - какого типа параметр у этого кондишена
    зажав ctrl - кликни на имени кондишена

    увидишь и его реализацию, и параметры

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

     похожая реализация и у кондишена - exactTexts (в этом кондишене - сравниваются тексты на равенство, а так - схема та же)

     вспомни - как ты использовала exactTexts для проверки списка тасок

     подумай - как переписать свою проверку (уже используя texts)
     чтобы эта проверка проверяла и нашу ситуацию  = в списке один элемент с вот таким текстом
     и чтобы можно было проверить этой же проверкой и список с несколькими тасками
*/
**********
    public static void refresh(){
/*
    .asf - достаточно
    остальные уточнения - уже лишние
*/
*******************************
/*

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

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

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

                    Gmail.visit();

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

*/