@Before
    public void openPage() {
        open("https://todomvc4tasj.herokuapp.com");
    }

  ....

    @Test
    public void testTaskFlow() {

        openPage();
/*
    раз уже метод openPage() аннотирован как Before
    вызывать в тест-методе openPage() - это делать openPage() дважды

    http://junit.sourceforge.net/javadoc/org/junit/Before.html
*/
***********************************
/*
    4 фиче-теста из 6 - работают на all фильтре
    неравномерно распределены покрытые операции по фильтрам
    это недостаток покрытия
*/
***********************************
//твой вариант
    @Test
    public void testDelete() {
        add("1", "2");
        assertTasksAre("1", "2");
        assertItemsLeft(2);
        delete("2");
        assertTasksAre("1");
        assertItemsLeft(1);
    }
//вариант, который советую я
    @Test
    public void deleteAtAll() {
        //given
        add("1", "2");

        delete("2");
        assertTasksAre("1");
        assertItemsLeft(1);
    }
/*
    оформление
        в названии тест-метода - указать - на каком фильтре покрываем фичу

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

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

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

        в именах тест-методов - придерживайся одной логики
        если начинаешь имя метода с test - то пусть это касается всех тест-методов
        когда то так, то так - это смущает - возникают ненужные вопросы к коду
        понятно, что в некоторых методах ты добавил в начале имени - test - чтоб была разница со вспомогательным методом
        в данном случае - в именах тест-методов будет указано - на каком фильтре покрываем действие
        и проблемы с одинаковыми именами вспомогательных методов и тест-методов  - в принципе не будет
*/
********************************************
//или - более интересный случай
        @Test
        public void editByClickOutsideField() {
            add("123");
            toggle("123");
            filterCompleted();
            assertTasksAre("123");
            startEditThenClickOutside("123", "123 edited");
            assertTasksAre("123 edited");

        }
//вариант, который советую я
        @Test
        public void editByClickOutsideAtCompleted() {
            //given - completed task
            add("123");
            toggle("123");
            filterCompleted();

            startEditThenClickOutside("123", "123 edited");
            assertTasksAre("123 edited");
            assertItemsLeft(0);
        }
/*
    те же моменты, что описывала выше

    уточняться в имени метода до Field - нет смысла
    мало что дает для наглядности и точности имени

    тут гивен-блок - уже посложнее
    и в комментарии - уже есть резон написать чуть больше - //given - completed task

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

    это стоит сделать - т к это практически не усложняет код
    но улучшает покрытие и точность проверок

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

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

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

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

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

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

    в итоге - с учетом этих рекомендаций - получим
*/
***************************************************
/*

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

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

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

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

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

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

*/