http://joxi.ru/xAe1zDPsYj3GYA

/*
    наверное, ты видел это и сам)
    у тебя в одном файле - 2 класса
    ToDoMVCTest и TaskStatus

    Я бы не стала в рамках одного файла вот так делать)
    пока - расположи  TaskStatus внутри класса ToDoMVCTest
    как ты и делал для класса Task

    Причем - советую их объявления - сделать рядом - так будет легче воспринимать информацию
    что до импортов - так вот такая строчка будет
    import static task6.ToDoMVCTest.TaskStatus.*;
    IntelIJ Idea сама тебе подскажет как правило - как импортить -
    если начать писать import static TaskStatus

    https://www.quora.com/Coding-Conventions-When-multiple-classes-are-placed-in-the-same-Java-file-why-should-only-one-of-them-the-class-that-contains-the-main-method-be-declared-public

    http://stackoverflow.com/questions/13132729/multiple-classes-in-single-file
    http://stackoverflow.com/questions/2336692/java-multiple-class-declarations-in-one-file
    http://stackoverflow.com/questions/968347/can-a-java-file-have-more-than-one-class
*/
***************************************
http://joxi.ru/vAW36KgskWp03A
/*
    не забывай форматировать код

    для этого - выдели код
    и в меню - code->reformat code

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

    сравни с текущей версией

    правило хорошего тона - выкладывать или отдавать в работу - стандартно отформатированный код
    причины просты - так код проще всего воспринимается - т к так нагляднее
*/
****************************
private void given(Task... tasks) {

/*
    с реализацией этого метода - согласна полностью

    можно написать чуть лаконичнее

    вместо
        "{\\\"completed\\\":" + task.taskStatus.toString()
        и
        "localStorage.setItem(\"todos-troopjs\", \"[" + joiner.toString()

    использовать
        "{\\\"completed\\\":" + task.taskStatus
        и
        "localStorage.setItem(\"todos-troopjs\", \"[" + joiner

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


    заметь - более нам не нужно заново еализовывать тот же (или почти тот же) алгоритм
    все остальные гивен-методы - будут реализованы через вызов этого, самого универсального
*/
**********************************************
private void givenAllActive(String... taskTexts) {
private void given(boolean isCompleted, String... taskTexts) {
private void given(TaskStatus taskStatus, String... taskTexts)

/*
    давай определимся - какие варианты гивен-метода нам нужны
    given(TaskStatus taskStatus, String... taskTexts) - позволит создать несколько тасок,
    в каком-то одном статусе
    однозначно, полезно, да и вызовы такого метода - лаконичные и точные

    вот сравни
    given(ACTIVE, "a", "b") -  и точно, и лаконично, и универсально - можно и закомпличеные таски добавить
    givenAllActive("a", "b") - тут - уже нету такой универсальности - меньше вариантов метод дает
    given(false, "a", "b") - тут  - не понятно - что хотели сказать первым параметром,
    при этом  - метод позволяет не больше, чем умеет given(TaskStatus taskStatus, String... taskTexts)

    получается - что варианта given(TaskStatus taskStatus, String... taskTexts) - достаточно

    удаляй given(boolean isCompleted, String... taskTexts) и givenAllActive(String... taskTexts)
    их рекомендовалось сделать - как первые попытки к реализации гивен-методов

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

    вот - первый из них - это given(TaskStatus taskStatus, String... taskTexts)
    только вот реализацию его - будем править

      задача - тебе внутри given(TaskStatus taskStatus, String... taskTexts)
        надо сделать то же, что ты делал в given(Task... tasks)
        просто - не ясно
        как из параметров (TaskStatus taskStatus, String... taskTexts)
        получить (Task... tasks)
         вот решим эту задачу - сможешь внутри
        given....(TaskStatus taskStatus, String... taskTexts)

        написать код в одну строчку
        given(xxx(taskStatus, taskTexts))

        в given(Task...tasks) в качестве параметра можно передавать массив Task[] tasks
        погугли про varargs in java

        реализуй метод xxx (про имя метода - сам подумай)
        возвращающий Task[]
        с параметрами (TaskType taskType, String... taskTexts)

        в котором
        объяви переменную типа Task[] и инициализируй ее как массив Task[....такого-то размера....]
        какого - посмотри на параметры нашего метода

        в цикле обойди taskTexts
        и каждый элемент массива заполни с помощью метода aTask

        верни полученный массив

        а далее - используй этот метод
        внутри given...(TaskType taskType, String... taskTexts)

            given(xxx(taskType, taskTexts))

        Если тяжело сразу  xxx реализовать -
        то для начала просто внутри givenAt....
        реализуй этот код - собери массив Task[] по переданным параметрам

        И тогда будет что-то типа такого
              Task[] tasks = ....
              ....
              ....
              ....
              given(tasks)
*/
********************************************
/*
    а дальше - еще добавим гивен-методов
    уже на все случаи жизни

    суть - все они используют внутри себя given(Task... tasks)
    и нужны - лишь для лаконичного вызова гивен-метода в тест-методе

    какие у нас задачи - реализовать full coverage с помощью фиче-тестов
    т е - фиче-тестов - будет много

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

    набора гивен-методов
     given(Task... tasks)
     givenAtActive(Task... tasks)
     givenAtCompleted(Task... tasks)

     given(TaskStatus taskStatus, String... taskTexts)
     givenAtActive(TaskStatus taskStatus, String... taskTexts)
     givenAtCompleted(TaskStatus taskStatus, String... taskTexts)

    тебе точно хватит для реализации любого варианта предварительных действий
    плюс к этому - достаточно просто понимаемые наборы параметров и сами названия методов
*/
**********************************************
/*
    еще можно чуть упростить наш код
      мы наследуем тест-класс от AtToDoMVCPageWithClearedDataAfterEachTest

        перед запуском теста - открываем наше приложение
        после - чистим локалсторидж

        гивены можно вызывать и для варианта, когда надо задать пустой список тасок
        (метод given(Task... tasks) - можно вызвать и с пустым набором параметров given())

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

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

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

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

        такого плана методы = если сейчас не так, то сделать так
        часто называют, начиная со слова ensure = обеспечить

        вот и не нужен нам код - по открытию урла в бифор-методе
        сразу вопрос - какой предок нужен тест-классу)

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

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

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

    как раз и поймешь - зачем столько гивен-методов)


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

    получится - что мы учтем в тестах больше нюансов
    проверим разные ситуации - т е лучшее покрытие реализуем
*/
************************************
given(new Task(ACTIVE, "B"), new Task(ACTIVE, "C"));

/*
    такого плана вызовы пожно упростить до
*/

given(aTask(ACTIVE, "B"), aTask(ACTIVE, "C"));

/*
    если у тебя будет метод aTask(...)
    возвращающий new Task(...)
*/