public static class Task {
        private String taskText;
        private String taskState;

        public Task(String taskText, TaskState taskState){
            this.taskText = taskText;
            this.taskState = taskState.toString();
        }
}

/*
     лучше для поля taskState - использовать тип TaskState

     когда собираешь строку
     "{\\\"completed\\\":" + task.taskState + ", \\\"title\\\":\\\"" + task.taskText + "\\\"}, "
     и к строке будешь добавлять task.taskState типа TaskState - все ок будет
     обїект класса TaskState будет преобразован к строке - согласно логике в toString()


     мало того)
     Ты можешь toString() организовать и в Task
     с тем чтобы возвращать
     "{\\\"completed\\\":" + task.taskState + ", \\\"title\\\":\\\"" + task.taskText + "\\\"}, "

     а в гивен-методе код упростится до - jsCode.concat(task.toString());

     работа с  toString() - на твое успотрение

     а вот тип поля   taskState - поправь)
     мотивы - просты
     ты всегда успеешь упростить тип до строки
     не надо это делать раньше времени)
     когда надо будет - тогда все до строки сведем
     а до этого - удобнее оперировать изначально  спроектированными типами
*/
****************************
    public enum TaskState {
/*
    тут - все ок

    все стало проще)
    и это хорошо
*/
****************************************
public static Task aTask(String taskText, TaskState taskState){
/*
    это - тоэе ок
*/
******************************************

    public static void prepareTasks(Task... tasks) {
        ...
        boolean flag = false;
        for (Task task : tasks) {
            ...
            flag = true;
        }
        if (flag) jsCode = jsCode.substring(0, jsCode.length() - 2);
        ...
    }
    /*
        можно вместо проверки if (flag)
        делать проверку if (tasks.length!=0)
        и тогда не понадобится переменная flag
        http://www.linkex.ru/java/varargs.php

        даже если в if-блоке - 1 команда
        используй фигурные скобки
        https://google.github.io/styleguide/javaguide.html#s4.1.1-braces-always-used

    */
***************************************************
    src / test / java / fullCoverageWithFT / GivenHelpers.java
/*
    GivenHelpers - класс с универсальными методами
    которые могут быть использованы в разных тест-классах (конечно, для приложения todoMVC)

    обычно универсальные классы равполагают в ветке проекта src / main/ java / ...

    поскольку сейчас в проекте - по пекеджам раздожены домашки
    то
        вариант 1
            в src / test / java / fullCoverageWithFT - делаем пекедж helpers
            и туда переносим GivenHelpers
        вариант 2
             в src / main / java / fullCoverageWithFT - делаем пекедж helpers
             и туда переносим GivenHelpers

        нас пока устроит вариант попроще - вариант 1
        дальше на курсе еще будет про это - про хорошую структуру проекта
        сейчас будет достаточно - если мы отделим тест-класс с его предком от вспомогательных классов
*/
****************************************************
     //given - add and complete task on All filter
     givenAtAll(COMPLETED, "a");
/*
    уже комментарии ни к чему
    гивен-методы - достаточно наглядны и так
*/
**************************************
public static final String baseUrl = "https://todomvc4tasj.herokuapp.com/";
...
    private void ensureAppOpened() {
        if (!baseUrl.equals(url())) open("https://todomvc4tasj.herokuapp.com/");
    }
/*
    ) переменную baseUrl - использовала не эффективно)

    if (!baseUrl.equals(url())) {
        open(baseUrl);
    }

    или даже так
    if (!url().equals("https://todomvc4tasj.herokuapp.com/")) {
            open("https://todomvc4tasj.herokuapp.com/");
    }

    да, не DRY
    но - урл в соседних строках повторяется
    потому - ок

    а если вариант с baseUrl нравится больше
    то - лучше объявить переменную прямо в методе
    она ведь больше и не нужна нигде

    в принципе - можно этот метод - перенести в GivenHelpers
    и вызывать в начале prepareTasks

    резоны - простые
    открытие урла - тоже можно рассматривать как предварительные действия
    да и такие действия никак не завязаны на другие вспомогательные методы
*/
**************************************
    private void givenAtAll(Task... tasks) {
            ensureAppOpened();
            prepareTasks(tasks);
            filterAll();
    }

    private void givenAtAll(TaskState tasksState, String... taskTexts) {
        ensureAppOpened();
        prepareTasks(makeTasksArray(tasksState, taskTexts));
        filterAll();
    }
/*
    за счет такой реазилации ensureAppOpened() - нам не нужен переход на all фильтр
    мы уже там)

    кстати - уйдет необходимость в методе given()

    вместо него - можно будет применить givenAtAll()
    т к varArgs-параметры подразумевают вызов - когда не передано ни одного параметра
*/
**********************************************
    private void givenAtActive(TaskState tasksState, String... taskTexts) {
        ensureAppOpened();
        prepareTasks(makeTasksArray(tasksState, taskTexts));
        filterAll();
    }
/*
    гивен-методы с параметрами (TaskState tasksState, String... taskTexts)
    можно переписать в одну строку
    givenAtActive(makeTasksArray(tasksState, taskTexts));
*/
********************************************

private Task[] makeTasksArray(TaskState tasksState, String[] taskTexts) {

/*
    метод стоит перенести в GivenHelpers

    и можно переименовать в aTasks (это по желанию, твой вариант названия тоже ок)
*/
***************************************

    @Test
    public void editCompletedOnAll() {
        //given - add and complete task on All filter
        givenAtAll(COMPLETED, "a");

        edit("a", "a edited");

        assertTasksAre("a edited");
        assertItemsLeft(0);

    }

    @Test
    public void editOnActive() {
         //given - add task on Active filter
         givenAtActive(aTask("v", ACTIVE));

         edit("v", "v edited");

         assertTasksAre("v edited");
    }

/*
    когда у нас гивен-методы - надежные и быстрые
    мы можем разнообразить тестовые ситуации

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

        ну и то - что ты учла -
            работаем с активной таской
            работаем с закомпличеной таской

        например на all-е
            гивен - одна активная, вторая - закомпличеная таска
            редактируем - вторую закомпличеную
        на activ-е
            гивен - первая активная, вторая закомпличеная
            редактируем первую и единственную видимую таску

        а в реализациях родственных действий - стараемся какие-то другие нюансы покрыть
        это нам даст  - лучшее покрытие, учитывающее кучу мелких моментов
        и при этом - мы не увелисили количество тест-методов
*/
***************************
    @Test
    public void completeOnActive() {
        //given - add task on Active filter
        givenAtActive(aTask("v", ACTIVE));

        complete("v");

        assertNoVisibleTasks();
        filterCompleted();
        assertVisibleTasksAre("v");
        assertItemsLeft(0);
    }
/*
    в данном случае - в рамках проверок не нужно переходить на другой фильтр,
    чтобы допроверить тестовую ситуацию

    достаточно проверить список тасок и счетчик активных тасок

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

        перешли на комплитед фильтр

        проверяем тексты тасок и счетсик активных тасок

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

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

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

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

    потому - подход, когда у нас есть совсем несного е2е-ов
    и много фиче-тестов - он эффективнее

    советую остановиться именно на варианте фиче-тестов)
*/
***********************************
    @Test
    public void deleteOnAll() {
        //given - add task at All filter
        givenAtAll(aTask("a", ACTIVE));

        delete("a");

        assertNoTasks();
    }
/*
    если в предварительных действиях - добавить пару тасок
    то - будет как проверить и items left
*/
***********************************************
если реализовывать full coverage - практически не оптимизируя- http://joxi.ru/DrlQ5oLh4PzRYm
допокрыть все, что еще не покрыто (вся оптимиация - не покрывать уже покрытое в е2е)

если оптимизировать - как я писала ранее - http://joxi.ru/EA4k7zEUDW5Bp2
и надо разобраться с приоритетом activate on all filter
если высокий/средний - то и это покрыть
если низкий - то не покрывать

по возможности - во всех фиче-тестах проверяй items left