public class ToDoMVC {
/*
    почитай про   conventions для имен тест-классов
    https://docs.google.com/document/d/10qSwWTQ6pGfVZSwOes-1QSmdflMiGD2U_y53VHq2m20/edit#bookmark=id.bligsp5b94xo
    и поправь имя тест-класса)
*/

    String task1 = "do something1";
    String task2 = "do something2";
    String task3 = "do something3";
    String task4 = "do something4";
    /*
        С таким вынесением тестовых данных в переменные надо быть осторожным - далеко не всегда это полезно.
        Часто тестовые данные разумно оставлять в логике самих тестов - таким образом код тестов более очевидный.
        Тут - как раз тот случай)

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

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

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

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

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


    @Test
    public void ToDo() throws InterruptedException {
    /*
        имя тест-метода тоже не отвечает conventions
        https://docs.google.com/document/d/10qSwWTQ6pGfVZSwOes-1QSmdflMiGD2U_y53VHq2m20/edit#

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

        мы это описали в общем - в имени тест-класса - тестируем мы приложение TodoMVC
        тут уже не повторяемся, и лишь уточняем
        если бы мы тестировали какую-то одну операцию - мы бы ее имя отразили в имени класса
        ну 2-3 так тоже моно отразить
        у нас получится слишком длинно - если следовать этой логике
        в таких случаях как часть фразы можно использовать LifeCycle, CommonFlow ....
        при этом - надо соблюсти конвеншенсы и уточнить - чей это флоу или жизненный цикл.
        В нашем случае это жизненный цикл тасок)

        throws InterruptedException  - тебе не пригодится
    */
        open("https://todomvc4tasj.herokuapp.com/");

        //Enter tasks
        $("#new-todo").setValue(task1).pressEnter();
        $("#new-todo").setValue(task2).pressEnter();
        $("#new-todo").setValue(task3).pressEnter();
        $("#new-todo").setValue(task4).pressEnter();
        /*
            Посмотри на задание - там эти действия описываются как create task...
            поскольку термин уже известен  - лучше его и придерживаться, а не вводить новый - //Enter tasks
            здесь и далее - мы будем придерживаться принципа = для одного понятия будем использовать только один термин
            в результате получим - максимально точный однозначно понимаемый код
            это очень важно)

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

        // Delete task
        /*
            пока код у нас такой - что не очень понятно - какую именно таску мы удаляем
            потому в комментарии стоит уточнить // Delete task2
            общее правило такое - если из кода что-то не понятно - поясняем комментарием
            при этом все равно стараемся его писать полаконичнее
            как только код написан понятно - и что делаем, и с какими тествыми данными работаем -
            комментарий либо сократится, либо вообще уйдет - на комментариях мы тоже будем экономить)
        */
        Thread.sleep(2000);
        /*
            В нормальных ситуациях, в тест-методах тебе не придется применять слипы
            У тебя есть набор ждущих проверок
            Мало того, в Selenide, когда мы вызвали click() (или любой другой метод, требующий видимости элемента),
            ожидание видимости элемента будет выполнено автоматически.
            Попробуй просто убрать эти слипы.
            Если у тебя нету проблем с качеством /скоростью канала интернета - так тест и без слипов отработает
            Если есть такие проблемы - можно увеличить интервал ожидания -
            Configuration.timeout установить вместо 4000(4 сек) бОльшее значение 10000(10 сек)
            делать это надо только если необходимо - сначала убедись в необходимости - убедись, что тест-метод падает без слипов
            Пока можно сделать вначале тест-метода - Configuration.timeout = 10000;
            Потом разберем - как это сделать правильно.
            Суть изменения такой настройки - ранее когда мы вызвали click() - мы ожидали в рамках 4 секунд -
            что элемент станет видимым. Теперь - ждем в рамках 10 секунд. В обоих случаях -
            если элемент становится видимым раньше этого интервала - код выполняется далее - т е лишних тормозов нету.

            Раз слипы ушли, то  убери и throws InterruptedException в зщаголовке метода
            Чем плохи слипы.
            Они гарантированно замедляют тест на столько-то времени.
            И при этом - не гарантируют выполнения факта - что мы дождались того, чего планировали
            Плохое сочетание - медленно и ненадежно

            Далее по курсу, и далеко не сразу, мы рассмотрим - когда нам нужен такой инструмент, как слип
            А общее правило такое - в логике самого тест-метода слипам не место)

            Далее про слипы уже не пишу)
        */
        $("#todo-list li:nth-of-type(2) label").click();
        /*
            В данном случае - можно было не уточняться до label
            А также - нам надо не кликнуть по таске
            А лишь навести на нее курсор мыши
            Это другой метод - не click()
        */
        $("#todo-list li:nth-of-type(2) button").click();
        /*
            button - технически верно получила селектор для кнопки
            предпочитай из нескольких вариантов - самый наглядный
            чтобы текст селектора уже рассказывал - что это за элемент
            выбирай, что отразить в селекторе, просматривая атрибуты в такой последовательности -
            id, class, name, other attributes. И выбирай наиболее подходящий вариант.
            http://joxi.ru/xAe1zDPsYEP63A - тут наиболее наглядный вариант - другой
        */
        /*
            про проверки результата выполненной операции далее не пишу...
            это и кода ниже - тоже касается
        */

        //Check task to complete and clear
        /*
            complete task4 and clear
            такой комментарий будет точнее и лаконичнее
        */
      ....

        //Mark all as completed and clear
        /*
            вот этого избегай - разных терминов для одного или похожих понятий
            Check task to complete или Mark all as completed
            лучше  - complete или complete all
            и лаконичнее, и в одних терминах
            упрости комментарий
        */
        ...