***

    @Test
    public void testDelete() {
        givenAtCompleted(COMPLETED,"1", "2");
        filterCompleted();
        delete("2");
        assertVisibleTasksAre("1");
        assertItemsLeft(0);
    }

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

ну то такое уже... мелочи... и субьективно... зависит от того в чем мы именно заинтересованы на проекте...

***

такс, теперь по твоим гивенам)

    @Step
    public void givenAtActive(TaskType taskType, String... taskTexts) {
        given(taskType, taskTexts);
        filterActive();
    }


    @Step
    public void givenAtCompleted(TaskType taskType, String... taskTexts) {
        given(taskType, taskTexts);
        filterCompleted();
    }

вот здесь поскольку идея гивенов - быть быстрыми, и использовать разные трюки вместо реальных юай действий,
то вместо filterActive
можно напрямую грузить нужный урл, обрати внимание что там есть свои урлы для каждого из фильтра... они заканчиваются на что то типа #/completed

оно по факту именно в нашем случае сильно на скорость не повлияет, но типа будет более "Феншуйно"... мы ведь в прекондишенах не тестируем переходы по фильтрам через реальные элементы юайа...

***
а так то в общем получилось неплохо, это примерно то что мы от тебя ожидали "для первого этапа"

но это была разминка:) Что бы помучать тебя и заставить пописать более сложный код со всеми этими форами и так далее...

Теперь же мы напишем более лаконичный и структурный код, использовав некоторые уже имеющиеся в джаве методы, и использовав более ООП стиль.

Смотри.

    public class Task {
        String taskText;
        TaskType taskType;

        public Task(TaskType taskType, String taskText) {
            this.taskText = taskText;
            this.taskType = taskType;
        }
    }

    @Step
    public String prepareGivenCommand(Task... tasks) {
        String results = "localStorage.setItem('todos-troopjs', '[";
        for ( Task task : tasks) {
            results = results +
            "{\"completed\":" + (task.taskType == TaskType.COMPLETED) + ",\"title\":\"" + task.taskText + "\"}, "; // вот эта часть кода по сути ведь описывает нашу задачу - просто "в ее текстовом представлении"...

Отсюда вопрос: почему тогда вещь которая касается описания задачи живет за границами класса задачи Task который как бы и существует для того что бы описывать все аспекты задачи?

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

Это тебе одна наводка ;)

а вот вторая: кроме вот этой части текстовой которая описывает задачу, у тебя в алгоритме присутствует код "склейки текстовых представлений задач" с помощью запятых, и "обрамления" их в квадратные скобки...

так вот... в джаве есть уже метод который делает это же, вот он: Arrays.toString(...)

ты просто ему передаешь масив обьектов, и он сам их трансполирует в строки, склеит их с помощью запятых, и в начале и в конце добавит квадрытные скобки ;)

***
и еще одна идея, которую тебе реализовывать не обязательно...
но мне например она нравиться:)

у тебя вот такой стиль:

        givenAtCompleted(COMPLETED,"1", "2");

он вполне норм)

но мне больше нравиться так:

        givenCompleted("1", "2");
        givenAtComplitedFilter();

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

правда поскольку читабельность это вещь субьективная - то и я тебя не буду заставлять переписывать в таком стиле...

но... если перепишешь таки, то получишь приятный бонус:) - сама реализация гивенов станет проще.

Во первых тебе уже не нужен будет твой енум.

Во вторых реализация логики текстового представления задач станет проще...

вместо (task.taskType == TaskType.COMPLETED)

вот здесь "{\"completed\":" + (task.taskType == TaskType.COMPLETED) + ",\"title\":\"" + task.taskText + "\"}"

ты сможешь просто писать task.taskType если сделаешь этот taskType типа boolean
ну и конечно тогда стоит его переименовать на isCompleted

а для того что бы вот этот синтаксис:

given(new Task(ACTIVE, "1"),new Task(COMPLETED, "2"));

не стал при этом таким вот уродским:

given(new Task(false, "1"),new Task(true, "2"));

достаточно добавить - либо статические методы active и комплитед которые скроют этот "false/true" ужос:

given(Task.active("1"), Task.completed("2"));

либо добавить дополнительные классы типа:

class ActiveTask extends Task {

    public ActiveTask(String text) {
        super(false, text)
    }
}

что бы потом писать:

given(new ActiveTask("1"),new CompletedTask("2"));

что в принципе тоже неплохо выглядит :)
Такие дела ;)

Все это делать конечно не сильно обязательно... Но это сделает твой код проще, чище, и более структурирование. Ну и научит тебя более обьектно ориентированному стилю... Который более популярный среди разработчиков.

P.S.
кстати... мы пока что не все делали обьектно ориентировано... мы даже до пейджобджектов еще не дошли... Но это уже вот вот начнется...

но так, на вырост...
Вот этот код:

        givenCompleted("1", "2");
        givenAtComplitedFilter();

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

given.completedTasks("1", "2").atCompletedFilter()

что тоже проще чем givenAtCompleted(COMPLETED,"1", "2");
именно изза того, что мы "разбили длинную цепочку параметров" на меньшие куски...

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