@Test
    public void testTasksLifeCycle() {

        add("1");
        toggle("1");
        /*
            нужна проверка
            тут мы проверим - что таска вне зависимости от статуса - на all видна
            а после перехода на Active - допроверим закомпличивание
        */

        filterActive();
        ...

        filterCompleted();
        ...
        assertNoTasks();

        /*
            надо было оставить переход на all
            и проверку текстов тасок

            ведь мы не реализовывали фиче-тест для перехода на   all
            получается - что эта высокоприоритетная операция осталась не покрытой
        */
    }
****************************************************
    @Test
    public void testDeleteTask() {
        add("1", "2");
        toggleAll();
        filterCompleted();
        delete("1");
        assertTasks("2");
        assertItemsLeft(0);
    }
/*
      по оформлению

      имя фиче-теста - что тестим и на каком фильтре

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

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

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

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

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

      в итоге - с учетом этих рекомендаций - получим
*/
    @Test
    public void testDeleteAtCompleted() {
        //given - completed tasks
        add("1", "2");
        toggleAll();
        filterCompleted();

        delete("1");
        assertTasks("2");
        assertItemsLeft(0);
    }
/*
    учти это и для других фиче-тестов
*/
**************************************************
/*

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

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

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

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

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

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