public class SmokeTest {
/*
    Имя тест-класса - должно отражать, что мы тестим
    То, что реализуем Smoke покрытие - это важная информация
    но - это не о тест-классе и не о тест-методе
    это о покрытии
    и оно может быть реализовано несколькими тест-методами разных тест-классов

    как показывать, что реализуем Smoke - это будет дальше на курсе

    сейчас - Smoke - убираем и из имени тест-класса и из имени тест-метода

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

    а чтобы этот тест-класс мог соседствовать в проекте с тест-классом - предыдущим заданием
    используй разные пекеджи
    в java - возможно в одном проекте держать классі с одинаковыми именами, но в разных пекеджах
*/
    @Test
    public void tasksSmokeTest() {
    /*
        нейминг
        учти комментарий выше
    */

        open("https://todomvc4tasj.herokuapp.com/");

        add("task1");
        edit("task1", "task2");
        /*
            разумнее вот так реализовать
            edit("task1", "task1 edited");

            это даст дальше понимание - что за таска была изначально и что мы с ней делали
        */
        assertTasksAre("task2");

        filterActive();
        /*
            было до перехода на нужный фильтр - в списке тасок таски с текстами = task2
            перешли на другой фильтр
            стало = то же самое - task2

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

            чтоб переход на фильтр хорошо протестировать - нужно, чтобы "было" отличалось от "стало"

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

            и мы максимально точно проверим фильтеринг
            это же учти - когда будешь и другие переходы по фильтрам покрывать
        */
        cancelEdit("task2", "task3");
        /*
            тут можно лучше
            cancelEdit("task2", "task2 edit calceled");

            тестовые данные будут пояснять - что мы делаем

            следующая операция add("task4") = не проверяет cancelEdit("task2"...
            значит - нужна проверка
        */
        add("task4");
        assertTasksAre("task2", "task4");
        toggle("task2");
        /*
            нет проверки
            filterCompleted(); - не проверяет операцию toggle("task2");

            еще раз перечитай то, что я в слеке тебе скинула
            про неявные проверки
        */

        filterCompleted();
        /*
            нет проверки
            почему?
        */
        clearCompleted();
        /*
            нет проверки
            почему?

            твои пояснения - нет, этого недостаточно

            проверка assertTasksAre("task2", "task4"); была гораздо выше по коду
            да и вообще - какая нам разница - что мы раньше проверяли
            мы смотрим на то - что делаем сразу после этого

            если следующая операция не проверяет предыдущую
            значит - нужна проверка

            представь - тест падает на последней операции - assertNoTasks();
            попробуй быстро понять - что конкретно отработало не так
            будут длительные разборки
        */

...
****************************
анализируем покрытие

public class SmokeTest {

all
        add
        edit
        delete

active
        cancel edit
        add
        complete

Completed
        clearCompleted

что еще не покрыто из высокоприоритетного
    complete all
    reopen

еще я советовала покрыть единожды
    items left
    посмотри еще один кусочек - про приоритеты - в слеке

грамотно - что на все 3 фильтра зашел
грамотно - что удаления отложил на конец сценария

но - с проверками есть проблемы
их не хватает, а некоторые из них - неточные
выше это описала

когда будешь complete all и reopen встраивать в свой сценарий
постарайся их распределить поравномернее - по фильтрам
идеально равномерно не получится, конечно
но это учти
*****************************
 ElementsCollection tasks = $$("#todo-list li");
/*
    есть вариант более точного селектора
    "#todo-list>li"

    тут и твой вариант рабочий

    но иногда эта разница может быть критично важной

    почитай про эту разницу - пробел  или > в селекторе
*/
*******************************
    private void filterActive() {
        $("#filters li:nth-child(2)").click();
    }

    private void filterCompleted() {
        $("#filters li:nth-child(3)").click();
    }

    private void filterAll() {
        $("#filters li:nth-child(1)").click();
    }
/*
    хорошее решение - что реализовал отдельный метод для перехода на каждый из фильтров
    почему это хорошее решение - почитай
    https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.8bflixemdgfw

    и вообще - в faq почитай про KISS и DRY принципы

    по реализации
    в нашем приложении - элементов a = ccылок = немного
    потому можно реализовать получение  элементов в этих методах проще и нагляднее -
    $(By.linkText(....))
*/
/*
    Также советую упорядочивать методы
    конечно, технически, порядок методов может быть любым

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

    рядом - аналогичные друг другу методы
    сначала - базовые операции, потом - остальное
*/