@Test
    public void testEditItemsLeft() {
    /*
         Поскольку будем покрывать ItemsLeft в каждом из фиче-тестов -
         можно это не указывать в имени тест-метода

         Но - в имени тест-метода стоит указать - на каком фильтре это проверяли

         testEditAtAll - будет ок
    */
        add("1");
        /*
            add - предварительное действие
            лучше это выделить в отдельный блок и снабдить комментарием
            //given ...
            ... - если предварительные действия сложные, то можно продолжить фразу - пояснить
            что же мы делаем в предварительных действиях
            если все просто - можно и не пояснять
        */
        edit("1", "1 edited");
        assertItemsLeft(1);
        assertTasksAre("1 edited");
        assertItemsLeft(1);
        /*
            после тестируемого действия - нам нужно выполнить 2 проверки
            важную - проверить состояние списка тасок
            и менее важную - то, что мы делаем по пути - состояние Items Left

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

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

            дважды проверять состояние ItemsLeft - смысла нету
        */
    }
/*
    если это все учесть, то получим
*/
    @Test
    public void testEditAtAll() {
        //given
        add("1");

        edit("1", "1 edited");
        assertTasksAre("1 edited");
        assertItemsLeft(1);
    }
/*
    второй фиче-тест - преобразуй по аналогии
    учти - что переход на нужный фильтр - это еще тестируемые действия

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

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

    пока мы реализуем given через действия на UI(User Interface) -
    без крайней необходимости переусложнять этот код не стоит
    (например, для cancel edit at Active - не надо комплитить одну из тасок)
    а вот когда будем реализовывать given серез работу с данными напрямую -
    то сможем себе позволить тестовые ситуации поинтереснее -
    т к это не будет ухудшать эффективность и надежность
*/
***********************************************
/*

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

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

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

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

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

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


*/