public void testTaskManagementE2E() {
/*
    имя тест-метода - testTaskManagement - уже подразумевает некий е2е сценарий
    иначе - мы бы в имени уточнили, какое действие тестируем

    так что - E2E - из имени метода убирай
    без потери точности будет
    но чуть лаконичнее
*/
*************************
    @Test
    public void testCancelEditByESC(){
        add("1");
        cancelEdit("1", "1_edited");
        assertTasksAre("1");
        assertItemsCountIs(1);
    }
/*
    в целом - все ок

    отошла от тест-плана - это планировала покрыть на Active фильтре
    и это было бы лучше - т к равномернее

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

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

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

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

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

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

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

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

        cancelEdit("1", "1_edited");
        assertTasksAre("1");
        assertItemsCountIs(1);
    }
*****************************************
    private void assertItemsCountIs(int count) {
        itemsCount.shouldHave(exactText(Integer.toString(count)));
    }
/*
    я б немного имя метода подравняла
    не ясно - что за Items (на User Interface - термин items count используется, и его стоит и нам использовать без сокращений)
    CountIs - на этом можно сэкономить), дальше параметр поясняет - что мы проверяем
    assertItemsLeft - будет точнее
*/
***********************************************
    private void assertNoItems() {
       itemsCount.shouldNotBe(visible);
    }
/*
    а вот тут лучше быть точнее - в имени метода

    ItemsLeft - по-прежнему применяем
    а дальше - точнее лучше быть
    не assertNoItemsLeft
    a  assertItemsLeftIsHidden

    так мы точнее опишем - что проверяем

    я бы кстати - вообще бы такую проверку не реализовывала
    т к это еще менее важная проверка
    не настаиваю

    а если добавить в предварительных действиях 2 таски
    то и после удаления таски - будет что проверить - я про ItemsLeft
*/
********************************************
/*
    порядок методов

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

    вначале - общие вещи, before/after методы,
    то, что отражает общую логику тест-класса

    потом - сами тест-методы (все)

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

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

    также не забывай про реформатирование кода
    есть немного моментов
       в IntelIJ Idea
        выдели код
        в меню(верхнем) - выбери пункт  - Code->Reformat code

        советую завести привычку - в конце работы - обязательно форматировать код
        вероятнее всего, ты будешь работать в команде, и твой код будут смотреть другие специалисты
        им проще смотреть на стандартно отформатированный код (как правило)
        иногда у команды есть свои правила форматирования, которые чуть отличатся от стандартных.
        Если все сделано по уму, то у всех членов команды в IntelIJ Idea именно так и настроено форматирование кода.
        Т е - все равно - привычка реформатировать код - нужна

        https://www.jetbrains.com/help/idea/2016.3/reformatting-source-code.html
*/
***************************************
/*

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

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

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

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

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

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


*/