@Test
    public void testTasksLifeCycle() {
    /*
        см прошлую работу - я писала про проверку assertItemsLeft в е2е
        или единожды покрой, или вообще не делай этого в е2е -
        т к в фиче-тестах это покроем

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

        addTasks("a");
        assertTasksAre("a");
        toggleAllTasks();
        /*
            нужна проверка
        */

        filterActive();
        assertVisibleTasksListIsEmpty();
        addTasks("b");
        toggleTask("b");
        assertVisibleTasksListIsEmpty();

        filterCompleted();
        assertVisibleTasksAre("a","b");
        //Activate
        toggleTask("a");
        assertVisibleTasksAre("b");
        clearCompleted();
        assertVisibleTasksListIsEmpty();

        /*
            ни в рамках е2е, ни в фиче-тестах - не покрыт переход на all фильтр
            в тест-плане - не было информации о том, что эта операция уходит из е2е

            поправь это
            проше всего - тут перейти на all
            и проверить - что таска а еще есть
        */
    }
************************************************
    @Test
    public void testTaskDelete() {
        addTasks("a","b");
        filterActive();
        assertItemsLeft(2);
        /*
            после предварительных действий - не нужно проверок
        */
        deleteTask("a");
        assertItemsLeft(1);
        /*
            assertItemsLeft - недостаточная проверка после действия
        */
        deleteTask("b");
        assertTasksListIsEmpty();
        /*
            в рамках фиче-теста  - достаточно лишь единожды покрыть тестируемое действие
            в рамках smoke покрытия - тоже - это лишнее
        */
    }

/*
    разберем на примере одного фиче-теста его реализацию и оформление
*/
/*
    имя фиче-теста - что тестим и на каком фильтре

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

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

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

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

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

    в итоге - с учетом этих рекомендаций - получим
*/
   @Test
    public void testDeleteAtActive() {
        //given
        add("a","b");
        filterActive();

        delete("a");
        assertTasksAre("b");
        assertItemsLeft(1);
    }
/*
    Также в примере - не использовала Task/Tasks в именах тест-методов и вспомогательніх методов-действий
    Я помню про твое мнение про это

    Настаивать не буду, хотела  показать более лаконичный вариант кода

    Если используешь в именах Task/Tasks - логику одну и ту же применяй
    В том числе это касается и порядка слов в названиях методов

    Эти приемы - примени ко всем фиче-тестам, что ты реализовал
*/

*********************************************************
    @Test
    public void testTaskCancelChanges(){
        ...
        startEditTask("a", "a edit canceled").pressEscape();
        ...
    }

    @Test
    public void testTaskUpdate(){
        ...
        startEditTask("a", "a edit").pressEnter();
        ...
/*
    Для одного понятия используй один термин

    сейчас = редактирование = edit или update или что-то про changes

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

        testCancelEditTask...
        testEditTask...
        startEditTask

        или

        testCancelUpdateTask...
        testUpdateTask...
        startUpdateTask

    обрати внимание на последовательность слов в именах - она тоже одна - что делаем +  с чем делаем + ...
*/

/*

    Это к общему сведению)

    Есть разные способы выполнять предварительные действия
    Мы сейчас делаем это через действия на UI (User Interface)
    А есть еще методы - работать непосредственно с данными (далее вы такое тоже попробуете)
    Так вот через действия на UI - предварительные действия не быстрые и часто не достаточно надежные
    А через непосредственную работу с данными - предварительные действия быстрые и надежные

    Если предварительные действия медленные или не надежные
    То проверка в конце предварительных действий нужна

    А если мы уверены - что после предварительных действий гарантировано все ОК,
    то и проверок не надо после предварительных действий

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

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


*/