<dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>2.53.1</version>
        </dependency>
/*
    Вот эта часть в pom - лишняя

    достаточно подключить Selenide - это враппер над селениумом
    потому и к функциональности селениумской получишь доступ,
    просто подключив Selenide
*/
****************************

public class MVCTest
/*
    приложение называется todoMVC
    потому правильнее тест-класс назвать - todoMVCTest

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

    в faq - есть раздел по неймингу
    там много полезного описано)
    https://docs.google.com/document/d/10qSwWTQ6pGfVZSwOes-1QSmdflMiGD2U_y53VHq2m20/edit#heading=h.2zj10n877t2p
*/
{
/*
    форматирование кода в твоей версии - отличается от стандартного

    IntelIJ Idea позволяет это легко подправить
    выдели код и в меню code->reformat code
    обрати внимание на то, как изменит свое положение эта фигурная скобочка)

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

*/
    @Test
    public void createTask() throws Exception {
    /*
        Метод - не только создание тасок тестирует
        он и другие операции тестирует - это у нас небольшой е2е сценарий

        обрати внимание на вот это
        https://docs.google.com/document/d/10qSwWTQ6pGfVZSwOes-1QSmdflMiGD2U_y53VHq2m20/edit#bookmark=id.txqig9rkgybo

        имя метода - поправь согласно рекомендациям

        насчет throws Exception
        вопрос - для чего это?
    */

        open("https://todomvc4tasj.herokuapp.com/");
        CommonActions todosOperations = new CommonActions();

//- Tasks #1-4
        todosOperations.FillTextBox("#new-todo", "Create Task 1");
        todosOperations.FillTextBox("#new-todo", "Create Task 2");
        todosOperations.FillTextBox("#new-todo", "Create Task 3");
        todosOperations.FillTextBox("#new-todo", "Create Task 4");
        /*
            сравни
            todosOperations.FillTextBox("#new-todo", "Create Task 1");
            $("#new-todo").setValue("Create Task 1").pressEnter();

            стало лаконичнее?
            стало нагляднее?
            стало понятнее?

            нет)

            так стоило ли прятать таким образом код?
            буквально в следующем видео - об этом будет подробнее)

            но в принципе, уже с твоими навыками можно по-другому реализовать это)
            код
            $("#new-todo").setValue("Create Task 1").pressEnter();
            реализовать как
            tasks.add("Create Task 1");
            или даже еще лаконичнее - если сделать более лаконичными тексты тасок
            tasks.add("t1");

            думаю, тебе уже понятно - как этого достичь
                объект класса CommonActions() - назвать tasks -
                мы же именно над тасками будем совершать действия
                и метод FillTextBox - упростить до add

                нам нужен метод, который добавит таску в список

                на уровне тест-метода -
                    нужен либо простой и наглядный метод
                    либо вообще не стоит ничего надстраивать сверху кода
                        $(...).setValue(...).pressEnter()
                        т к этот код сам по себе - достаточно прост

            кстати - имена методов - должны начинаться с маленькой буквы
                https://google.github.io/styleguide/javaguide.html#s5.2.3-method-names
        */

//-Additional task        //Just checking that all values are added to the TODO
        $$("#todo-list li").shouldHave(exactTexts("Create Task 1", "Create Task 2", "Create Task 3", "Create Task 4"));
        /*
            проверка правильная и к месту

            а вот комментарии излишни)
            и так все понятно
        */

//- Task #5
        todosOperations.ClickToDosButtons("Create Task 2", ".destroy");
        /*
            тоже - сравни - что ты выиграл, пряча реализацию
            todosOperations.ClickToDosButtons("Create Task 2", ".destroy");
            $$("#todo-list li").find(exactText(elementPath)).hover().find(".destroy").click();

            тут - да, немного выиграл)

            а могло бы быть
            tasks.delete("Create Task 2")
            или вообще вот так
            tasks.delete("t2")

            заметь - я чуть переписала
             find(".destroy")
             вместо
             find(By.cssSelector(".destroy"))
            технически - это одно и то же
            у SelenideElement -
            есть методы find и с параметром типа By, и со строковым параметром - чтобы сразу оперировать css селектором

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

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

            вопрос - что поясняет комментарий   //- Task #5?
            мне не становится понятнее, например
            а значит - насколько он нужен?
        */

//- Task #6
        todosOperations.ClickToDosButtons("Create Task 4", ".toggle");
        /*
            для закомпличивания таски - нам не нужно выполнять hover
            чекбокс toggle - и так видим
            достаточно его просто найти внутри таски

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

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

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

            сравниваем
            todosOperations.ClickToDosButtons("Create Task 4", ".toggle");
            $$("#todo-list li").find(exactText("Create Task 4")).find(".toggle").click();

            выигрыш в лаконичности - есть, но не большой)

            а могло бы быть
            tasks.xxxx("Create Task 4")
            tasks.xxxx("t4")

            xxxx - подумай над именем метода
            попробуй вот это учесть
            https://docs.google.com/document/d/10qSwWTQ6pGfVZSwOes-1QSmdflMiGD2U_y53VHq2m20/edit#bookmark=kix.x92tktmmfsz2

            насчет проверки после этой операции...
            тут ситуация поинтереснее
            в принципе - проверку можно отложить на 1 шаг
            и проверить состояние списка тасок после clear completed
                так можно поступить - т к проверка текстов тасок после закомпличивания таски
                даст нам проверку логики = все таски на all фильтре отображаются независимо от своего статуса,
                но не даст проверку факта закомпличивания
                это мы как раз допроверим после clear completed
                проверка текстов после clear completed как раз этот факт и допроверит
        */

//- Task #7
        $("#clear-completed").hover().click();
        /*
            тут тоже hover() ни к чему

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

            нужна проверка после действия
        */

//- Task #8
        todosOperations.ClickToDosButtons("Create Task 3", ".toggle");
        todosOperations.ClickToDosButtons("Create Task 1", ".toggle");
        todosOperations.ClickOperationButtons("All");
        /*
            тут имелось в виду - другое действие
            с использованием вот этого переключателя
            http://joxi.ru/p275M9zs0eBkVr

            перепиши этот кусок кода

            по аналогии с complete task 4 & clear completed -
            тут тоже можно проверку отложить на после clear completed
        */

//- Task #9
        $("#clear-completed").hover().click();
        /*
            проверка?
        */
    }
}
/*
    резюме насчет реализации тест-класса

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

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

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

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


*/
***************************
/*
   ты спрашивал
        у меня была идея сделать список, положить туда значения тудушек,
        и из него в форИче заполнить, но наверное смысла для 4х штук нет

   на самом деле, тут 2 вопроса)
        использовать ли для тестовых данных переменные
        как можно реализовать добавление нескольких тасок, вызвав один метод

   начнем со второго вопроса)
        почитай про varargs parameters http://www.linkex.ru/java/varargs.php
        намекну - что можно реализовать добавление тасок - используя varargs parameters
        в результате чего - будешь вызывать метод - tasks.add("t1", "t2", "t3", "t4")
        если пока с этим сложно - отложи
            это будет разобрано в следующем видео
            пока - просто знай, что так реализовать  добавление тасок - можно)
            технически можно, и это усложнение метода add оправдано - т к иногда в начале тест-метода
            действительно - будет требоваться создать несколько тасок сразу - в рамках подготовки тестовой ситуации

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

                С вынесением тестовых данных в переменные надо быть осторожным - далеко не всегда это полезно.
                Часто тестовые данные разумно оставлять в логике самих тестов -
                таким образом код тестов более очевидный = KISS.
                Тут - как раз тот случай)

                Используй в качестве текстов тасок что-то лаконичное
                (task1, task2 .../ t1,t2,..../ a,b,..../ 1,2,....)
                Тогда код будет по-прежнему наглядный и не загроможденный и при этом - простой для восприятия
                Важно - чтобы код теста был как можно более очевидным и простым - с первого взгляда на него.

                И потому тестовые данные - как правило - не стоит выносить в переменные -
                чтобы не приходилось при анализе кода отвлекаться на то, что это за переменные,
                где объявлены или чем инициализированы.
                Почитай про KISS principle

                Какие тестовые данные стоит выносить в переменные.
                То, что применяется в нескольких методах и является строго определенным (не произвольные данные,
                а какие-то конкретные). Пример - логин-пароль для аккаунта, или какие-то предопределенные данные -
                которые всегда есть на начало работы с приложением.

                У нас - другой случай. Просто тестовые данные, которые нужны в единственном тест-методе.
                Эти данные не какие-то строго определенные - они такие, какими мы их решили сделать = произвольные
                И у нас нет цели использовать значение - длинные строки, которые будут загромождать код.
                В таких случаях - лучшим решением будет просто указывать в коде значения текстов тасок,
                без использования дополнительных переменных.
                Ну и, конечно, разумно остановиться на лаконичном варианте - для текстов тасок -
                чтобы код не загромождать.

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

*/


public class CommonActions
/*
    если ты таки решил оставить класс - давай назовем его правильно)

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

    таким объектам дают имена, заканчивающиеся на Page
    (TodoMVCPage - будет ОК)

    и размешают в пекедже pages

    это мы сильно забежали вперед)

    но - с твоей подачи)))

    те элементы или коллекции - которые будут использоваться в нескольких методах - выноси в переменные
    например
        public ElementsCollection tasks = $$("#todo-list li");
    цель - не повторять в коде - один и тот же селектор
    в долгосрочной перспективе - это даст выигрыш - меньше придется подправлять код тестов при изменении
    тестируемого приложения

    теперь можно используватьпеременную tasks как в коде этого класса
    так и в коде тест-класса - уже нигде повторно не оперируем $$("#todo-list li")
    используем переменную
*/

    public void ClickOperationButtons(String buttonName)
/*
    такой метод тебе пока не нужен вообще

    как переделать остальные - выше писала
*/