https://bitbucket.org/murnatko/todomvctest/src/3973483e2669/src/test/java/ua/net/itlabs/hometask/smoke/?at=master

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

    http://joxi.ru/L210nzMu6PlKvm
    вот тут кликай)
*/
********************************************
/*
    сначала приведу общее полезное - то, что еще не использовано

    Использование неявных проверок
    про использование неявных проверок через действие
              вариант 1
              add("task1"");
              edit("task1", "task1 edited");
              delete("task1 edited");

              вариант 2
              add("task1", "task2");
              edit("task2", "task2 edited");
              delete("task2 edited");

           Вариант 1 = правильное использование таких проверок через действие

           Вариант2 = не правильное использование
           Т к последующие действия не проверяют состояние ВСЕХ тасок в списке

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

           Также не забывай - после каждого действия должна быть выполнена проверка
           Сразу
           Не получается использовать неявную проверку через следующее действие - используй явную
           Но - действие должно быть обязательно проверено сразу

*/
public class TodoMVCTest {

    @Test
    public void tasksLifecycle(){

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

        add("1", "2", "3");
        /*
            разве тебе прямо на следущем шаге нужны все 3 таски?

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

            еще учти - что add("1", "2", "3"); - это все равно 3 действия)
            так что - одновременное добавление нескольких тасок - это не экономия )
            потом еще добавишь тасок - это действие единственное, которое невозможно
            покрыть единожды
        */
        assertItemsLeft("3");
        /*
            вот такой вариант вызова
            assertItemsLeft(3);
            когда параметр - это число
            более точный
            мы же проверяем количество тасок
            количество = число

            эта проверка - недостаточна для проверки операции add("1", "2", "3")
            тут не хватает проверки текстов списка тасок

            а вот если бы мы добавили лишь одну таску
            то и операция editEsc("1", "new");
            будет проверять )
            т к проверит состояние всего списка (у нас же всего 1 таска - ее и проверили)
        */

        editEsc("1", "new");
        /*
            лучше бы назвать cancelEdit - т к что делаем = отменяем редактирование
            про Escape  - уточнять не надо
            т к это единственный способ выполнить cancelEdit

            cancelEdit("1", "1 edited")
            cancelEdit("1", "1 edit canceled")
            - такие тестовые данные лучше пояснят - что мы делаем
            использовать тестовые данные для пояснений кода -
            хороший способ избежать лишних комментариев)
        */
        assertTasksAre("1", "2", "3");
        /*
            хорошо, что тут есть проверка
            это ок
        */

        switchFilter("Active");
        /*
            по поводу реализации переходов по фильтрам
            почитай вот это
            https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.8bflixemdgfw

            и попробуй применить
            и вообще посмотри на разделы про DRY & KISS principles )
        */
        assertTasksOfTypeAre("active", "1", "2", "3");
        /*
            заметь - такая проверка пройдет и на all фильтре
            и даже если здесь, на Active фильтре будут отображаться закомпличеные таски
            то проверка assertTasksOfTypeAre("active", "1", "2", "3"); - тоже пройдет

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

            посмотри на http://joxi.ru/l2ZNaR0F83gJv2
            и вот это видео
            https://drive.google.com/file/d/0B8hgIBw8-V-AdGxxU1R3enl1RzQ/view?usp=sharing

            мы можем быть максимально точными и держать 4 проверки
                2 -
                    в списке = такси с такими-то текстами
                    в списке = пусто
                и еще 2 -
                    в отфильтрованном по visible списке = таски с такими-то текстами
                    в отфильтрованном по visible списке = пусто
                И за точность будем платить  тем - что надо думать - когда какую проверку вызвать правильнее
                и если это делать бездумно - то при небольших изменениях сценариев - могут тесты падать на проверках,
                или второй вариант - не будем нормально пользоваться полученной точностью...

                мы можем исходить из того, что ошибку, когда невидимые таски копятся в списке - мы тестим на более низком уровне,
                и на UI уровне - нам не нужно до этого уточняться. Поэтому - мы будем держать всего 2 проверки
                      в отфильтрованном по visible списке = таски с такими-то текстами
                      в отфильтрованном по visible списке = пусто
                В таком случае - каждый раз понятно - какую проверку вызывать - получаем более KISS картину
                правда, платим за это точностью) Но - возможно - если мы уже отдельно это в тестах покрыли -
                что у нас не копятся невидимые таски - так мы и не платим ) И - тогда - все проще в написании тестов,
                и в их сопровождении.
                Тогда - поскольку обе проверки реализованы одинаково и других нету - можно из имен проверок скрыть этот нюанс
                и назвать их assertTasks и assertNoTasks (хотя в них работаем с отфильтрованным по visible списком тасок)

                Это отнеси ко всем проверкам списка тасок

            так, теперь вернемся к нашей тестовой ситуации)
            было в списке - "1", "2", "3"
            перешли на нужный фильтр
            стало в списке - "1", "2", "3"

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

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

        toggle("1");
        assertTasksOfTypeAre("active", "2", "3");

        toggleAll();
        assertNoTasks("active");
        /*
            во как раз complete - покроешь на одном фильтре
            а complete all - на другом
        */

        switchFilter("Completed");
        assertTasksOfTypeAre("completed", "1", "2", "3");
        /*
            а вот тут круто получилось)
            перед переходом на Completed - не было видимых тасок
            перешли на Completed
            и тут - в списке видимы такие-то таски
            тут - проверили переход на другой фильтр - точно
        */

        toggle("1");
        assertTasksOfTypeAre("completed", "2", "3");

        clearCompleted();
        assertNoTasks("completed");
        /*
            идеально)
            хороший выбор для Completed фильтра

            единственное - если на момент clearCompleted()
            будет лишь одна таска - то будет чуть экономнее)
        */

        switchFilter("All");
        assertTasksAre("1");
        /*
            и тут ок переход на фильтр проверили)
        */

        edit("1", "new");
        /*
            edit("1", "1 edited") - лучше прояснит дальше  - что за таска "1 edited"

            советую покрыть эту операцию на Active фильтре
            так будет равномернее
            нам равномерное распределение по фильтрам даст вот что
            даже на уровне smoke теста мы вероятнее увидим проблемы -
            если на каком-то из фильтров не будут работать операции над тасками

        */
        delete("new");
        assertNoTasks();
        /*
            это тоже удачное решение - покрыть удаление таски под конец сценария
        */

    }
****************************************
    private static ElementsCollection tasks = $$("#todo-list li");
/*
    "#todo-list>li" - такой селектор точнее
    нам тут и твой вариант подходит

    но - бывают ситуации - что вот такое уточнение критично
*/
    private static ElementsCollection filters = $$("#filters li");
/*
    не уверена - что нам нужна такая переменная
    по-прежнему считаю - что в нашем случае до нужных элементов
    можно добраться проще - $(By.linkText(...))
    мы это обсуждали в skype)
*/
*******************************************
    private void assertTasksOfTypeAre(String taskType, String... taskTexts) {
        tasks.filter(cssClass(taskType)).shouldHave(exactTexts(taskTexts));
    }
/*
    filter - ты уже применять умеешь)
    нам нужен просто другой кондишен)
*/
***********************************
    private void assertNoTasks(String taskType) {
        tasks.filter(cssClass(taskType)).isEmpty();
    }
/*
    isEmpty() - просто вернет boolean-значение - да или нет
    а проверка  - это другое в нашем случае
    если проверка проходит - тест должен дальше выполняться
    а не проходит - так тест должен упасть
    такое поведение - у should-методов
*/
***************************
    private void assertItemsLeft(String itemLeftText) {
        $("#todo-count").shouldHave(text(itemLeftText));
    }
/*
    про тип параметра - писала

    text - првоеряет на вхождение текста в текст элемента

    например - в элементе - текст 10 elements left
    а мы проверяем - assertItemsLeft(1)
    и такая проверка пройдет)

    уточни элемент "#todo-count"
    и уточни проверку
*/
*****************************************************
    private void edit(String taskText, String newText) {
        tasks.find(exactText(taskText)).doubleClick();
        tasks.find(cssClass("editing")).$(".edit").setValue(newText).pressEnter();
    }

    private void editEsc(String taskText, String newText) {
        tasks.find(exactText(taskText)).doubleClick();
        tasks.find(cssClass("editing")).$(".edit").setValue(newText).pressEscape();
    }
/*
    термин taskText - хороший термин для текста таски

    а для обозначения было-стало - хорошо использовать old и new, или from и to
    oldTaskText & newTaskText

    подправь имена параметров

    про имя editEsc - писала выше

    посмотри - как переименовывать
    https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#heading=h.vwuqi54t6fyg

    еще чуть код улучшим
    вот этот код
    tasks.find(exactText(taskText)).doubleClick();
    tasks.find(cssClass("editing")).$(".edit").setValue(newText)

    повторяется в 2-ух методах

    реализуй метод xxx(...)
    который возвращает SelenideElement = элемент, в котором ввели новый текст
    чтобы его вызывать xxx("1", "1 edited").pressEnter()

    про имя метода подумай
    это старт/начало редактирования
*/
************************
    private void switchFilter(String filterType) {
        filters.find(exactText(filterType)).click();
    }
/*
    выше писала - что почитать
    и как лучше реализовать
    надеюсь, этого хватило)
*/