http://joxi.ru/DmBNWL6FNR7YLm

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

    давай немного структурируем
        1 - предки тест-класса
        в этом же пекедже  - сделай пекедж для них - testconfigs

        2 - классы для реализации гивен-методов
        сами эти классы - нам отдельно от гивен-методов - не нужны
        потому вот так держать их отдельно в структуре проекта - смысла большого нету
        да, пока, в этом задании, гивен-методы мы реализуем прямо в тест-классе
        позже - разберем - как вспомогательные методы вынести из тест-класса
        сейчас я тебе предлагаю расположить классы Task & TaskStatus - в самом тест-классе
        потом - в следующих заданиях - эти классы вместе с гивенами - мы отделим от тест-класса
        но - по-прежнему  классы Task & TaskStatus  и гивен-методы - будут реализованы в рамках одного класса
        т к все это служит одной цели и по отдельности нами применяться не будет
        почитай про nested classes in java
            https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html
            https://www.tutorialspoint.com/java/java_innerclasses.htm

        3 - собственно тест-класс
            вот он и останется в корне этого пекеджа
*/
************************************
script += "{\"completed\":"+ task.status + ", \"title\":\"" + task.name + "\"},";

....

public class Task {
    String name;
    boolean status;

    public Task(String name, TaskStatus status){
        this.name = name;
        this.status = status.getValue();
    }
}

/*
    ну да )
    красиво конечно ты выкрутилась)

    преобразовала статус на уровне класса Task в  boolean-значение
    и уже использовала строковое представление boolean-значения в гивен-методе )

    красота мне нравится)
    но - не нравится вот что
    на уровне - кога мы смотрим на объект типа Task
    и смотрим на его статус - то нам тяжело понять - что это значение -
    true or false - для нас значит

    более просто для понимания общей картины - чтобы и класс Task оперировал статусом типа TaskStatus

    но - как же красота?

    до нее на самом деле - один шаг)

    если на уровне TaskStatus ты реализуешь метод toString(), возвращающий
    "true" or "false" - то значения типа TaskStatus будут преобразовываться к строке именно так - как прописано в
    toString()

    все классы - в том числе и enum - это потомки класса Object
    у которого есть такой метод  toString()
    отвечающий за преобразование объекта к строке

    и если ты в своем классе  - реализуешь метод  toString()
    то именно так объект этого класса и будет преобразовываться к строке

    и тогда в выражении
    script += "{\"completed\":"+ task.status + ", \"title\":\"" + task.name + "\"},";
    где  task.status - будет значением типа TaskStatus - тоже будет все хорошо

    то есть  - красота решения осталась,
    но ушел его недостаток - на уровне Task мы оперируем статусом типа TaskStatus

    можно пойти еще дальше )
    реализовать toString() в классе Task

    чтобы в гивен-методе писать
    script += task + ",";

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

    также для полей name и status советую уже сейчас использовать модификатор доступа
    сейчас это не важно - т к классы в одном пекедже
    (когда не указан модификатор доступа - получаем package-private вариант)
    https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
    http://stackoverflow.com/questions/16164902/what-is-the-default-access-modifier-in-java
    мы впоследствии перенесем гивен-методы с классами Task & TaskStatus в другой класс
    и этот класс - будет жить в другом пекедже
    вообще - разумнее сразу использовать модификатор доступа (access modifier) явно
    чтобы при реструктуризации проекта не приходилось заботиться о видимости переменных или методов
*/
*************************************
    public void given(Task... tasks)
    ...

    public void givenAtAll(Task... tasks)
    ...

    public void testDeleteAtCompleted(){
        givenAtAll(new Task("task1", COMPLETED));

        filterCompleted();

/*
    реализовывать ли метод-синоним givenAtAll(Task... tasks) для given(Task... tasks) - еще вопрос...

    а вот для тестов на Active & Completed фильтре - хорошо бы иметь свои гивен-методы
    которые и локалсторидж подготовят, и переход на нужный фильтр выполнят - ведь это тоже
    предварительное действие

    т е - нам нужен набор

    given(Task... tasks) - собственно реализация алгоритма подготовки даных

    givenAtAll(Task... tasks) - этот можно и не реализовывать, т к это просто вызов given(Task... tasks)
    givenAtActive(Task... tasks)
    givenAtCompleted(Task... tasks)

*/
**********************
 givenAtAll(new Task("task1", COMPLETED), new Task("task2", COMPLETED));

 /*
    во многих случаях тебе нужны несколько тасок в одном статусе
    и такого рода код
    givenAtAll(new Task("task1", COMPLETED), new Task("task2", COMPLETED));
    можно переписать лаконичнее
    givenAtAll(COMPLETED, "task1", "task2");

    согласись, гораздо лаконичнее - что важно для тест-методов

    тебя есть
            givenAtAll(Task... tasks)
            givenAtActive(Task... tasks)
            givenAtCompleted(Task... tasks)


         для удобства работы мы хотим реализовать дополнительно
            givenAtAll(TaskStatus taskStatus, String... taskTexts)
            givenAtActive(TaskStatus taskStatus, String... taskTexts)
            givenAtCompleted(TaskStatus taskStatus, String... taskTexts)


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

         тебе нужно уметь преобразовывать
         (TaskStatus taskStatus, String... taskTexts)
         в
         (Task... tasks)

         в методы с параметрами (Task... tasks) можно передавать значения-массивы (Task[] tasks)

         вот и напиши метод
         возвращающий Task[]
         по данным (TaskStatus taskStatus, String... taskTexts) - это будут его параметры

         таким образом
         внутри
         givenAtAll(TaskStatus taskStatus, String... taskTexts)

         ты сможешь вызывать
         givenAtAll(xxx(taskStatus, taskTexts))

         про имя такого метода  xxx надо подумать )
 */
 ************************************
 givenAtAll(new Task("task1", ACTIVE), new Task("task2", COMPLETED), new Task("task3", ACTIVE));

 /*
    сравни
    givenAtAll(new Task("task1", ACTIVE), new Task("task2", COMPLETED), new Task("task3", ACTIVE));
    и
    givenAtAll(aTask("task1", ACTIVE), aTask("task2", COMPLETED), aTask("task3", ACTIVE));

    вот такой метод aTask, создающий новый объект типа Task - тоже может сделать код тест-метода лаконичнее
    не настаиваю на применении, но в общем - прием оправданный
 */
*******************************************
       @Test
       public void testDeleteAtAll(){
           givenAtAll(new Task("task1", ACTIVE), new Task("task2", COMPLETED), new Task("task3", ACTIVE));
           assertItemLeft(2);
           /*
            после вызова гивен-метода - нам не нужны проверки
            гивен-методы - быстрые и надежные
            достаточно проверок после тестируемого действия

            касается всех без исключения тест-методов
           */
***********************************
    @Test
    public void testDeleteAtActive(){
        givenAtAll(new Task("task1", ACTIVE));
        filterActive();

        delete("task1");
        assertNoVisibleTasks();
    }

    @Test
    public void testDeleteAtCompleted(){
        givenAtAll(new Task("task1", COMPLETED));

        filterCompleted();

        delete("task1");
        assertNoVisibleTasks();
    }
/*
    в тестах одного и того же действия - используй разные тестовые ситуации

     да, в тесте на all удаляется одна из нескольких тасок, это ок

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

     а можно и вот так
        удалить единственную таску
        удалить единственную видимую таску(есть еще и не видимые)

     просмотри и остальные тест-методы относительно разнообразия тестовых ситуаций
*/
**************************
    @Test
    public void testCompleteAllAtAll(){
        givenAtAll(new Task("task1", ACTIVE), new Task("task2", ACTIVE));
        assertItemLeft(2);

        toggleAll();

        filterCompleted();
        assertTasksAre("task1", "task2");
        assertItemLeft(0);
    }
/*
    судя по всему - ты засчитала переход на Completed - в покрытие

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

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

    да и в имени тест-метода тогда надо отразить - что тестировали не только CompleteAll
    но и переход с All на Completed

    и уже по реализации
    вспомни
    мы об этом говорили - когда делали е2е для smoke покрытия
    когда мы точно проверили переход на другой фильтр
        состояние списка изменилось = переход на фильтр работает
        состояние списка правильное = переход на фильтр работает правильно

    разве у нас так?

    возможно, е2е тест   CompleteAll + Clear Completed at All
    был бы лучше - в том плане - каждое из этих тестируемых действий было проверено достаточно точно

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

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

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

    на самом деле, фиче-тесты - будут эффективнее
    т к тестирование каждой из фич - будет независимым

*/
*****************************
    @Test
    public void testActivateAtAll(){
        givenAtAll(new Task("task1", COMPLETED));
        assertItemLeft(0);

        toggle("task1");
        assertItemLeft(1);

        filterActive();
        assertVisibleTasks("task1");
    }
/*
    тут - примерно тоже

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

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

    в этом тест-метода - примерно тот же набор проблем, что и тесте testCompleteAllAtAll()

*/
************************************
   @Test
    public void testClearCompletedAtAll(){
        givenAtAll(new Task("task1", COMPLETED), new Task("task2", COMPLETED));

        filterCompleted();
        clearCompleted();
        assertNoVisibleTasks();
    }
/*
    странный метод)

    в названии указали - тестируем ClearCompleted на All фильтре

    а в реализации - мы это делаем на Completed фильтре

    если в гивен-методе - создать не только закомпличеные, но и активные таски
    то можно будет проверить и счетчик активных тасок
    та и действие ClearCompleted будет протестировано точнее
    нам же важно не только то, что закомпличеные таски удаляются
    но и то, что активные - остаются
*/
*********************************
    @Test
    public void testCancelEditAtActive(){
/*
    для шкалы из 3-ех приоритетов  - у этого действия явно приоритет 1

    это действие без workaround

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

    в любом случае - такое надо покрыть на всех контекстах в рамках full coverage

    не призываю менять шкалу приоритетов
    призываю -
        поменять приоритет на высокий (точнее = равный приоритету edit,
        на completed фильтре - как и у edit, приоритет будет ниже)
        и покрыть и на all, и на active  фильтрах
*/
***************************************************
/*
    из раздела Additional edit operations:
    у нас куда-то ушел вариант     confirm edit by press Tab
    причем еще на уровне предыдущих задаий)

    тут http://pastebin.com/SJFFt6KZ
    он еще был

    соглашусь с 3-им приоритетом

    даже при оптимизации полного покрытия - низкоприоритетное надо покрыть на каком-то одном из контекстов
    добавь недостающий пункт в тест-план и реализуй тест-методы
    тоже - распределяй их по разным фильтрам и думай про разнообразие тестовых ситуаций - т к методы тестируют
    похожие операции
*/
************************************
    @Test
    public void testCompleteAllAtActive(){
        givenAtAll(new Task("task1", ACTIVE), new Task("task2", ACTIVE));
        filterActive();

        toggleAll();
        assertNoVisibleTasks();

        filterCompleted();
        assertVisibleTasks("task1", "task2");
    }
/*
    ну ладно CompleteAll на All фильтре
    там и правда  - можно посчитать - что недостаточно проверить список тасок и счетчик активных тасок

    но тут, на Active фильтре - состояние списка тасок отлично отражает - что операция выполнена корректно
*/
**************************************
    @Test
    public void testActivateAllAtActive(){
        givenAtAll(new Task("task1", COMPLETED), new Task("task2", COMPLETED));
        assertItemLeft(0);

        filterActive();

        toggleAll();
        assertItemLeft(2);
        assertVisibleTasks("task1", "task2");
    }
/*
    не согласна, что на Active фильтре - эта операция будет иметь средний приоритет

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

    а на Active, также как и на all - приоритет у этой операции будет низкий
*/
***************************************
/*
    советую - как и написано в условии задания - дореализовать к нашему е2е - именно фиче-тестов для полного покрытия

    я бы не стала реализовывать маленьких е2е - чтобы поточнее проверить некоторые из действий на all
    как писала выше - за счет того - что есть фиче-тесты на все действия, в том числе и на фильтеринг
    в любом из фиче-тестов - проверок состояния списка тасок и счетчика активных тасок  - достаточно

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

    покрывай проверку счетчика активных тасок как вторую проверку после тестируемого действия
    этого - достаточно
    старайся - чтобы было что проверять - чтобы на конец теста счетчик активных тасок можно было проверить
    не во всех ситуациях это можно сделать
    практически во всех)
    когда отражаешь в тест-плане - что покрыла items left
    то выбирай строку тест-плана, соотвествующую действию, ПОСЛЕ которого выполнила проверку items left

    проверки после гивен-методов - не нужны в фиче-тестах
    это мы еще разбирали в задании Smoke e2e+F

    приведу и тут этот кусочек
*/

/*

    Optimized full coverage
    Судя по всему, ты уже оптимизировала покрытие
    это было делать не обязательно, но можно

    что можно оптимизировать
        - что покрыто в е2е - не покрываем фиче-тестами
        - низкоприоритетное - покрываем единожды, на каком-то из контекстов (пример - delete by emptying text)
        - низкоприоритетные варианты фичи, у которой есть покрытые варианты - не покрываем (пример - reopen all & add)

*/

/*

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

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

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

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

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

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


*/
***********************
private void add(String... taskTexts)

public class Task {
  ...

    public Task(String name, TaskStatus status){
/*
    это уже придирка)

    ранее мы использовали термин taskText
    я бы из этих соображений - и в классе Task
    использовала не name, а text

    ну или уже title - т к именно так это называется в локалсторидже

    цель - оставаться в одних терминах
*/