public class BaseTest {

    static {
        Configuration.timeout = 15000;
    }

    @After
    public void tearDown() throws IOException {
        screenshot();
    }

    @Attachment(type = "image/png")
    public byte[] screenshot() throws IOException {
        File screenshot = Screenshots.takeScreenShotAsFile();
        return Files.toByteArray(screenshot);
    }
}
/*
    Такой предок тест-класса пригодился бы для различных тест-классов

    портит картину лишь Configuration.timeout = 15000;
    это стоит перенести непосредственно в тест-класс
    т к это особенность конкретно этого тест-класса

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

    почитай про Single Resopnsibility Principle
*/
****************************

public class GmailSendAndSearchTest extends BaseTest {
/*
    Вспоминаем)
    имя тест-класса - описываем в общем - что же мы тестируем
    в общем - мы тестируем  Gmail )
    GmailTest - вполне достаточно

    а вот в имени тест-метода - можно и уточниться)
*/
    @Test
    public void sendAndSearchTest(){
      /*
         мы тут тестим - login, send and search

         а также - вспомни про конвеншенсы для имен тест-методов
      */
        open("http://gmail.com");

        Gmail.loginToGmail(Credentials.email,Credentials.password);
        /*
            Если пейдж - Gmail
            и вызываем метод пейджа, указывая и имя класса пейдж-модуля
            то метод можно назвать и лаконичнее
            Gmail.login(Credentials.email,Credentials.password); - не хуже ничем)
            точности не потеряешь, а лаконичнее - будет
        */
        Gmail.sendMail(Credentials.email, "Topic");
        /*
            Gmail.send(...) - тоже достаточно точно )

            читаем задание
            search the arrived mail by topic and ensure only 1 is present in search results

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

            это сделать можно разными способами, например, добавив к "Topic" = дату-время в милисекундах
        */

        Gmail.refresh();
        Gmail.assertMailPresent(0,"Topic");
        /*
            Gmail.assertMail(0,"Topic"); - будет лучше )
            мы ведь не просто наличие письма проверяем)
            а то, что такое-то по счету письмо содержит такой-то текст
        */

        Gmail.goToSend();
        /*
            точнее будет - не Send, а Sent
        */
        Gmail.assertMailPresent(0,"Topic");

        Gmail.goToInbox();
        Gmail.search("Topic");
        Gmail.assertResultCount(1);
        /*
            Хорошо бы проверить не только то, что найдено одно письмо, но и то, что это наше письмо
            наше письмо = содержит наш уникальный топик
        */
**************************************

public class Gmail {
...

    public static void loginToGmail(String login, String password) {
 /*
    селекторы можно упростить - input - лишнее
*/
*****************************
    public static void sendMail(String login, String topic) {
/*
    все ли ок у тебя с работой с русскими буквами?
    $(byText(“НАПИСАТЬ”)) may not work on windows because of encoding issues.
    you can switch to English in Gmail Settings to avoid such issues and use locating by “english captions”

    для полей кому и топик - можно найти локаторы понагляднее
    просмотри у элементов - id, class, name, other attributes

    login - имя параметра = емайл получателя
    не очень удачное имя)
    подбери более точное

    про имя метода - писала выше)

*/
****************************
    public static void refresh(){
/*
    нужно ли уточнять в селекторе элемент-родитель?
    проанализируй - можно ли без ущерба для точности сократить селектор
*/
***********************************
    public static void goToInbox(){
    public static void goToSend(){
/*
    Обрати внимание на tilte єлементов
    есть такой метод byTitle(...)

    за счет этого можно получить код понагляднее
*/
****************************
    public static void assertMailPresent(int id,String topic) {
/*
    реализация  - ок
    вопросы - по неймингу
    выше писала про имя метода

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

    topic - мы не точно topic письма сопоставляем
    мы проверяем - что такой-то текст содержится в описании мейла
    так что и для этого параметра надо имя получше подобрать)
*/
******************************
    @Step
    public static void search(String topic){
        $("input[name='q']").setValue("subject:"+topic).pressEnter();
    }
/*
    можно использовать $(By.name("q"))

    а вот и сюрприз)

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

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

    @Step
    public static void assertResultCount(int count){
/*
    уже писала - что проверки количества результатов - недостаточно

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

    есть аналогичный кондишен, который точно также проверит количество и порядок текстов
    только тексты сравнит не на полное соотвествие, а на вхождение
*/
******************************************

/*
  http://joxi.ru/nAyqEx7HXvxQoA

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

  в src \ main

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


  в src \ test

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


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

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

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

*/
*****************
/*
    Также - попробуй прикинуть
    как можно было бы использовать не один пейдж-модуль, а несколько (2-3)
    тут, это, конечно, за уши притянуто

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

    если не будет идей - в следующий раз подскажу больше)
    ну или в слек приходи)
*/