public enum TaskType

  public class Task

  public String prepareGivenCommand5(Task... tasks)
/*
    эти 2 класса и метод - реализованы ок

    убирай рабочие комментарии отсюда

    и куски закомментаренных предыдущих версий этих классов

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

    тут - убираем мусор
    кода будет много, потому избавляемся от всего лишнего
*/
************************************************
    @Step
    public void prepareGivenCommand(){
        String jsCommand = prepareGivenCommand5 (new Task("a", TaskType.ACTIVE), new Task("b", TaskType.COMPLETED));
        System.out.println(jsCommand);
        executeJavaScript(jsCommand);
        refresh();
        assertTasks("a", "b");
    }
/*
    я не такую задачу перед тобой ставила

    был нужен метод given(Task... tasks)

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

    т е метод = реализующий нужное нам состояние списка тасок
    чтоб мы при вызове метода - задавали самостоятельно - что за набор тасок нам нужен
    а у тебя - прошито раз и навсегда - активная a + закомпличеная b
    стоило городить огород такой - если мы со снаружи не будем задавать набор тасок

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

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

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

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

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

*/
********************
public String prepareGivenCommand...
/*
    все вот эти ранее реализованные prepareGivenCommand - реализуют то же самое что и prepareGivenCommand5
    только в prepareGivenCommand5 - все универсальнее

    вызвав prepareGivenCommand5 - мы можем любой вариант состояния списка тасок реализовать

    нам все вот эти prepareGivenCommand... - были нужны - лишь для того - чтоб понять - методом пошагового усложнения
    что ж нам в итоге нужно

    но вот так держать - кучу методов с почти одинаковым кодом - очень вредно
    почитай про DRY принцип (в нашем FAQ)

    стратегия такая
    если нужно реализовать что-то для тебя сложное - начинаешь с простого
    и пошагово усложняешь-уточняешь
    когда получил окончательный универсальный вариант - все предыдущие шаги удаляешь
    получишь - что алгоритм реализован ЕДИНОЖДЫ

    и если тебе нужны варианты с набором параметров попроще - уже используешь этот реализованный метод
    для реализации методов с параметрами попроще
    ниже эту мысль поясню

    пока - все  prepareGivenCommand... кроме prepareGivenCommand5 - удаляй
    сам prepareGivenCommand5 - переименовывай в prepareGivenCommand

    если что-то нужно для твоих внутренних нужд - как выше писала - выноси куда-то, систематизируй
    и потом используй
    тут, в коде, никаких закомменченных рабочих кусков или лишнего кода остаться не должно
    уже к следующему ревью)
*/
************************
 @Test
    public void testCancelEditTaskAtActiveFilter() {
        //given
        add("a");
        filterActive();

        cancelEdit("a", "a edited canceled");
        assertTasks("a");
        assertItemsLeft(1);
    }
/*
    мы договаривались - что в тест-методах - уже будут реализованы предварительные действия через вызов given(Task... tasks)
    реализуй это

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

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

    реализуй
    givenAtActive(Task... tasks)
    givenAtCompleted(Task... tasks)

    в котором - вызовешь given(Task... tasks) и переход на нужный фильтр

    это то, о чем я говрила ранее
    в одном методе given(Task... tasks) - будет реализоан алгоритм
    а далее - будем его переиспользовать для реализации других гивен-методов
         цель которых = выполнить то же  что и given(Task... tasks)
         и еще что-то, к примеру, - как с переходом на нужный фильтр у нас происходит
         эту тему и далее развивать будем
         пока - выполни задание вот в таком объеме

    дополнительно - реализуй тест-метод
    testReopenAllAtCompleted - где используешь givenAtCompleted (работай с несколькими тасками, потом объясню - зачем)

    в остальных тест-методах - воспользуйся тем гивен-методом, который будет более уместен в той ситуации
    цель = все предварительные действия выполняются в гивен-методе
*/