public class TodoMVCUseCases {

    @Test
    public void taskWorkFlow(){
        open("https://todomvc4tasj.herokuapp.com/");

        add("task1");
        confirmEdit("task1", "task1 edited");
        assertEdited("task1 edited");
        /*
            отлично распорядилась возможностью неявных проверок
            про нейминг и по реализации методов - напишу ниже

            проверка текстов тасок в списке перед переходом на другой фильтр - правильное решение
        */

        clickFilterActive();
        assertTaskAre("task1 edited");
        /*
            смотри тут какая ситуация
            были в списке таски - "task1 edited"
            перешли на другой фильтр
            стали в списке таски - "task1 edited"

            с одной стороны - состояние списка правильное
            что хорошо

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

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

            если еще покрыть на all перед переходом на active фильтр
            complete "task1 edited"
            то
            у нас бы было
                        были в списке таски - "task1 edited"
                        перешли на другой фильтр
                        стали в списке таски - пусто
            мы бы проверили и фильтеринг, и допроверили - закомпличивание таски
        */

        toggleAll();
        assertTasksAreNot();
        /*
            маловато мы на active фильтре проверили операций
            лучше - распределить операции поравомернее по фильтрам
        */

        clickFilterCompleted();
        /*
            нужна проверка - каждую операцию проверяем сразу
        */
        clearCompleted();
        /*
            нужна проверка
        */

        add("task2");
        /*
            вспомни - добавление таски на Completed фильтре - мы не включали в список основных юз кейсов
            и не зря)
            тут, на этом фильтре - это редко будут делать

            нужна проверка
        */
        clickFilterAll();
        assertItemLeft(1);

        cancelEdit("task2", "task2 edited");
        assertEdited("task2");
        /*
            вот это для бОльшей равномерности можно было и на active фильтре покрыть
        */

        toggle("task2");
        clearCompleted();
        /*
            clearCompleted(); - покрыли выше
            попробуй найти вариант - когда не потребуется повторять clearCompleted();

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

            такое повторение плохо еше и тем - что мы таким образом удаляем таску
            и приходится еще и добавлять дополнительную таску
        */
        assertEmpty();

        add("task3");
        delete("task3");
        /*
            а если бы мы покрыли activate на Completed фильтре
            то тут бы как раз было - что удалить)
        */
        assertEmpty();
    }
**************************************************
      All
            add
            confirmEdit


      Active
            complete all

      Completed
            clearCompleted
            add

      All
            cancelEdit
            complete
            clearCompleted
            add
            delete

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

    еще надо покрыть - activate
    это очень удобно проверить на Completed фильтре

    как уже выше писала - стоит complete перенести выше по сценарию - еще до перехода на active фильтр покрыть
    так уйдет лишний clearCompleted и лишний add

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

    также советую сдвинуть и cancelEdit на active фильтр

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

    в целом - движение верное
        что-то покрыли на all
        перешли на active
        затем на completed
        и вернулись на all

    и переходы на каждый из фильтров по разу покрыли
    и есть возможность точно проверить все фильтеринги (да и допроверить кое-что из ранее сделанного)
*/
*******************************************

    private SelenideElement changeTextInTheEditField(String oldTaskText, String newTaskText){
/*
    я бы назвала метод startEdit/beginEdit
    по сути - мы именно это и делаем - начинаем процесс редактирования таски

    если хочется быть точнее - то что-то типа твоего варианта
    startEditChangingText, например
    changeTextInEditField - тоже можно, думаю что и без The - смысл не потеряется

    варианты startEdit или startEditChangingText - мне нравятся больше
    т к мы главное говорим в самом начале - что это только начало редактирования

    изменение имени - рекомендую, но не настаиваю

    с реализацией - все ок
*/
*****************************
    private void confirmEdit(String oldTaskText, String newTaskText){
/*
    это - стандартный вариант для редактирования
    потому - можно и edit

    для более сложных вариантов подтверждения редактирования - согласна
    придется что-то типа confirmEditByPressTab писать

    а тут - можно и без подробностей

    тоже не настаиваю
*/
*********************************
    private void assertTaskAre(String taskText){
        tasks.shouldHave(CollectionCondition.exactTexts(taskText));
    }
/*
    в прошлой работе у нас был похожий метод, но более универсальный
    который в качестве параметров принимал String... taskTexts

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

    и тут разумно держать более универсальную версию
    более универсальная версия позволит проверить и ситуацию, когда одна таска в списке
    и ситуацию, когда их несколько

    посмотри предыдущее задание
*/
*******************************
    private void assertTasksAreNot() {
        tasks.filter(visible).shouldBe(empty);
    }

    private void assertEmpty(){
        tasks.shouldBe(empty);
    }

/*
    предлагаю назвать методы assertNoTasks и  assertNoVisibleTasks - понятнее и нагляднее

    в прошлой работе это я пропустила)
    и там метод назывался assertEmpty()

    не надо в методах-проверках из имени что-либо скрывать
    тут всегда надо быть однозначным
    надо было указать - что должно быть empty

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

    если тебе важно - поправь в предыдущей работе имя метода assertEmpty()

    в assertTasksAreNot ты использовала фильтрацию по visible списка тасок
    да, если такой метод применять на active или completed фильтрах - это действительно хорошее решение

    также и для проверки текстов - если проверять тексты тасок на active или completed фильтрах -
    фильтрация по visible тоже понадобится

    посмотри вот это видео - и прими решение насчет набора проверок
    https://drive.google.com/file/d/0B8hgIBw8-V-AdGxxU1R3enl1RzQ/view?ts=567ab8d7
    пояснения к видео
    мы можем быть максимально точными и держать 4 проверки
        2 -
            в списке = такси с такими-то текстами
            в списке = пусто
        и еще 2 -
            в отфильтрованном по visible списке = таски с такими-то текстами
            в отфильтрованном по visible списке = пусто
        И за точность будем платить  тем - что надо думать - когда какую проверку вызвать правильнее
        и если это делать бездумно - то при небольших изменениях сценариев - могут тесты падать на проверках,
        или второй вариант - не будем нормально пользоваться полученной точностью...

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

    имя метода - должно точно отражать то, что метод делает

    такого нельзя сказать о методе assertEdited
    т к все очень зависит от контекста - смотря где в сценарии такой метод вызвали
*/
*************************************
    private void clickFilterAll(){
    private void clickFilterActive(){
    private void clickFilterCompleted(){
/*
    с реализацией - ок

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

    что делаем - фильтруем + как фильтруем
    filterAll
    filterActive
    filterCompleted
*/
*********************************
    private void assertItemLeft(int itemCount){
/*
    используй import static для Condition.exactText
    и тогда в коде можно будет использовать exactText

    т к это параметр метода shouldHave - и так понятно, что работаем с кондишеном
    потому без ущерба для понятности можно использовать exactText вместо Condition.exactText
*/
**************************************************