givenAtActive(aTask(ACTIVE, "1"));
или
givenAtActive(ACTIVE, "1");
/*
    раз у нас такой набор гивен-методов - лучше использовать самый лаконичный вариант

    просмотри все вызовы гивен-методов
    еще есть такие моменты
*/
*************************
    @Test
    public void testAddOnActive() {
        givenAtActive(aTask(ACTIVE, "1"));

        add("2");
        assertTasksAre("1", "2");
    }
/*
    Если это технически возможно - покрывай и assertItemsLeft(0);
    и проверки уточнишь, и покрытие улучшишь - нам в рамках full coverage полезно проверить работу этого счетчика
    при разных комбинациях - ситуаций + контекстов + выполненного последнего действия

    Да и не очень это усложнит тест-метод (я говорю о фиче-тестах)

    Подозреваю - что ты петалась и это соптимизировать
    Я бы не стала

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

    касается и других тестов
*/
**************************************
    @Test
    public void testCompleteAllOnActive() {
        givenAtActive(aTask(ACTIVE, "1"), aTask(ACTIVE, "2"));

        //complete all
        toggleAll();
        assertNoTasks();
        filterAll();
        assertTasksAre("1", "2");
    }
/*
    тут уже комментировать //complete all - стоит ли
    в общем-то ясно - что тестим  - из имени метода

    что касается перехода на filterAll();
    я бы в рамках этого теста - после toggleAll();
    проверила список тасок + Items Left

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

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

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

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

    дальше (конечно, по возможности)
    стоит дополнять покрытие фиче-тестами (их еще атомарными тестами называют при случае)
*/
*************
  public void testReopenOnCompleted() {
/*
    покрытие ты оптимизируешь
    потому - не стоит покрывать в фиче-тесте то
    что покрыто в е2е
*/
***********************
    @Test
    public void testClearCompletedOnCompleted() {
        givenAtCompleted(aTask(ACTIVE, "1"), aTask(COMPLETED, "2"));

        assertTasksAre("2");

        clearCompleted();
        assertNoTasks();
        assertItemsLeft(1);
    }
/*
    придерживайся одного принципа
    мы не делали проверок после гивен-методов в других тест-методах
    и тут не будем

    да и не надо - если посмотреть на все разработанные фиче-тесты в комплексе
    и если вспомнить  про то - если гивен-методы надежны - то не нужно проверок после них
*/
********************************
   @Test
    public void testDeleteOnAll() {
        given(ACTIVE, "1", "2", "3");

        delete("2");
        assertTasksAre("1", "3");
        assertItemsLeft(2);
    }

    @Test
    public void testDeleteOnActive() {
        givenAtActive(aTask(ACTIVE, "1"), aTask(ACTIVE, "2"));

        delete("1");
        assertTasksAre("2");
    }
/*
    По сути - это одна тестовая ситуация
    у нас несколько тасок, все видимы
    и мы удаляем какую-то из них
    не совсем одна, конечно - ты работаешь с первой илине первой таской

    можно усугубить)
    я бы для Active - использовала ситуацию, когда есть одна видимая таска, и одна не видимая
*/
********************************
/*
    посмотри на комменты в тест-плане - надо бы дополнить покрытие
*/
**********************************
private static ElementsCollection tasks = $$("#todo-list>li");
/*
    особого смысла объявлять переменную как static - нету

    как доступиться к этой коллекции из гивен-метода - поясню

    а больше и нет причин или целей)

    про разницу между статик и не статик - уже давала линку
     http://www.javamadesoeasy.com/2015/06/differences-between-instance.html
*/
private void given(Task... tasks) {

        String jsCode;
        /*
            предлагаю объявить переменную попозже)
        */

        if .....
        /*
            этот if - я бы завернула ensurePageOpened() / ensureAppOpened()
            и тут бы вызывала этот метод

            часто имена методов начинают с ensure - когда нужно что-то обеспечить =
            если нету ... то сделать это
        */

        ...

        for (int i = 0; i < tasks.length; i++) {
        ....
        /*
            получилось бы чуть лаконичнее - если использовать
            for(Task task:tasks)
        */

        jsCode = String.join(",", jsContent);
        jsCode = "....".concat(jsCode).concat("....");
        /*
            я бы  вместо объявления переменной и вот этих 2-ух строк

            вот так написала бы - в одну строку
            String jsCode = "....".concat(String.join(",", jsContent)).concat("....");
            или даже
            String jsCode = "...." + String.join(",", jsContent)) + "....";
            просто потому что читать легче

            мы конечно немного потеряем в скорости используя + вместо concat
            вот тут было про это
            http://stackoverflow.com/questions/47605/string-concatenation-concat-vs-operator

            ну то уже вкусовщина)
            я бы предпочла ясность и лаконичность кода)
        */

        ....
        TodoMVCTest.tasks.shouldHaveSize(tasks.length);
        /*
            раз коллекция tasks = $$("#todo-list>li") - не статик
            то тут ее можно получить как this.tasks

            https://docs.oracle.com/javase/tutorial/java/javaOO/thiskey.html
            http://stackoverflow.com/questions/2411270/when-should-i-use-this-in-a-class
        */
    }
*****************************************
    private Task[] applyStateForTasks(TaskState taskState, String... taskTexts){
 /*
    этот метод я бы по аналогии с aTask - назвала бы aTasks, или даже также aTask
    (если сигнатуры у методов разные - то можно методы с одни и тем же именем создавать в java)

    и тогда вызовы givenAt....(aTasks(ACTIVE, "a", "b", "c")) - тоже достаточно лаконично )
    т к - я смотрю - не для всех фильтров ты реализовала given-метод с параметрами (TaskState taskState, String... taskTexts)

    тут уже - или такие методы дореализовать
    или этот убирай
    и потом будешь вызывать givenAt....(aTasks(ACTIVE, "a", "b", "c")) при необходимости

    а то не понятно
    почему гивен-методы с параметрами (Task... tasks) - для каждого фильтра
    а с параметрами - (TaskState taskState, String... taskTexts) - только для all

 */
****************************************
 private static class Task {
   ....
        public Task(TaskState value, String name) {
        /*
            более общепринято - имя параметра конструктора и имя поля класса называть одинаково
            value - замени на state

            name - я бы поменяла на text (и имя параметра, и имя поля
            причина - мі везде в тестах єто называем текстом таски
            ну или если хочется быть точнее - то title - как это на уровне локалсториджа называется
        */

        @Override
        public String toString(){
            StringBuilder task = new StringBuilder("{\\\"completed\\\":");
            return task.append(state.value).append(", \\\"title\\\":\\\"").append(name).append("\\\"}").toString();
            /*
                тут бы я тоже написала лаконичнее
                return new StringBuilder("{\\\"completed\\\":").append(state.value).append(", \\\"title\\\":\\\"").append(name).append("\\\"}").toString();

                или все же  - для лакничности используя + для конкатенации
                return "{\\\"completed\\\":" + state.value + ", \\\"title\\\":\\\"" + name + "\\\"}";
                (напоминаю - вот это  - уже моя вкусовщина)

                а в одну строку переписать стоит
                когда объявление переменной не дает тебе каких-то выигрышей в понятности-наглядности
                так и не надо ее объявлять )
            */
        }

    }