см комментарии к тест-плану
***************************************************
public class Preconditions {

    ...
    private final List<String> taskStatus;
    /*
        taskStatuses

        насчет использования String - спорно
        но - т к это все внутри билдера, то в общем-то - приемлемо
    */
*****************************************
        public PreconditionBuilder atAllFilter() {

            this.filter = "https://todomvc4tasj.herokuapp.com/#";
            return this;
        }

        public PreconditionBuilder atActiveFilter() {

            this.filter = "https://todomvc4tasj.herokuapp.com/#/active";
            return this;
        }

        public PreconditionBuilder atCompletedFilter() {

            this.filter = "https://todomvc4tasj.herokuapp.com/#/completed";
            return this;
        }

        public Preconditions build() {

            if (!url().equals("https://todomvc4tasj.herokuapp.com/")) {
                open("https://todomvc4tasj.herokuapp.com/");
            }
            ...
            open(this.filter);
/*
    https://todomvc4tasj.herokuapp.com/ - строка повторяется многократно
    и в разных методах
    вынеси в отдельную переменную и используй

    теперь про код
    сначала - прийти на https://todomvc4tasj.herokuapp.com/
    потом - наполнить локалсторидж
    потом - переоткрыть урл согласно фильтра

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

    учти вариант вызова given().build() - чтоб тоже корректно работал
*/
****************************************
    public Preconditions build() {

          ...
          //делаем все действия
          ...

          return new Preconditions(this);
          //именно это мы строим
        }
    }
/*
    чтобы четче выдержать паттерн - лучше, чтобы
    вот эти все действия - выполнял сам объект Preconditions

    т е - в методе build() - свести к коду
    вместо
        делаем действия
        return new Preconditions(this)
    реализуем
        тут - только return new Preconditions(this)
    а в Preconditions - делаем метод prepare()
        который как раз и выполнит эти действия

    тогда - мы четко выдержим паттерн

    получаем варианты вызовов
    given().build().prepare();
    given().activeTasks(...).completedTasks(...).atAllFilter().build().prepare();

    вот эти build().prepare() - многословно, конечно
        можно немного доработать)
        в рамках PreconditionBuilder - создать метод void prepare()
        который вызывает как раз build().prepare()


    и получим чуть попроще
    given().prepare();
    given().activeTasks(...).completedTasks(...).atAllFilter().prepare();

    и в то же время - реализованная структура позволит вот так сделать
        Preconditions preconditions = given().activeTasks(...).completedTasks(...).atAllFilter().build();

        и потом - использовать это несколько раз
            preconditions.prepare();

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


    т е построенный объект и его действия - все же разделены

    теперь про термины
        preconditions и givens - синонимы
        надо бы использовать один термин)
        я и про имена методов, и про имена классов

*/
*********************************
http://joxi.ru/52akqzoUGPPkvr
http://joxi.ru/BA0p30gsBLLpDA
http://joxi.ru/DmBNWL6FNEEgJm
/*
    1 - форматирование отличается от стандартного
    2 - используешь пропуски строк по-разному
    несколько пропущенных строк - уже лишнее
    достаточно одной пропущенной строки - чтобы код отформатировать

    чтобы реформатировать код - выдели код + code->reformat code

    про применение пропусков строк
    https://google.github.io/styleguide/javaguide.html#s4.6.1-vertical-whitespace
*/
**************************************
http://joxi.ru/vAW36KgskJJBoA
/*
    не надо отдельного пекеджа test

    уже мы в ветке src/test/java/com/todomvc

    перенеси тест-классы на уровень выше
*/
****************************************
    @Test
    public void testCreate(){

        given().atActiveFilter().build();

        page.create("a");
        page.assertVisibleTasks("a");
        page.assertItemsLeft(1);
    }
    @Test
    public void testCreate(){

        given().atAllFilter().build();

        page.create("a");
        page.assertTasks("a");
        page.assertItemsLeft(1);
    }
/*
    для тест-методов одного действия - применяй разные тестовые ситуации
    например, тут - в одном случае - добавляем первую таску
    а во втором - вторую

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

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

    в чем оптимизация
        - что покрыто в е2е - не покрываем фиче-тестами
        - низкоприоритетное - покрываем единожды, на каком-то из контекстов (пример - delete by emptying text)
        - низкоприоритетные варианты фичи, у которой есть покрытые варианты - не покрываем (пример - reopen all & add)
    ты многие идеи уже применил
    единственное - что нужно бы вернуть е2е
    его можно сделать проще (я бы не стала на это тратить время тут)
    но вообще убрать - не стоит
*/
************************************************
    @Test
    public void testEdit(){
        given().activeTasks("a").atActiveFilter().build();

    ...
    @Test
    public void testEdit(){
        given().activeTasks("a").atAllFilter().build();
/*
    и тут, и далее - позаботься о разных тестовых ситуациях
    уже про это не пишу далее
*/
*****************************************
    @Test
    public void testDelete(){

        given().activeTasks("a", "active to delete").completedTasks("b", "completed to delete").atAllFilter().build();

        page.delete("active to delete");
        page.delete("completed to delete");
        page.assertTasks("a", "b");
        page.assertItemsLeft(1);
    }
/*
    в фиче-тесте - покрывай одно действие

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

    а для е2е - проверок поболее нужно

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

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

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

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

    уже немного было про pair wise testing в каком-то из видео)
    http://qcthoughtsaloud.blogspot.com/2010/06/pairwise-testing.html
*/
**************************************

    public void testMoveToAll(){
    public void testMoveToCompleted(){
/*
    точнее было бы testSwitchTo...

    это про имя

    и про реализацию
    советую использовать в каждом из тестов как активные, так и закомпличеные таски

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

    т к нам нужны еще и разные тестовые ситуации
    можно учесть
        по одной таске в разном статусе
        по парочке тасок в разном статусе
        таски в разном статусе вперемешку (одна такая, вторая не такая, третья - опять такая....)
*/
******************************
    @Test
    public void testConfirmEditClickOutside(){

        given().activeTasks("a").atActiveFilter().build();

        page.startEdit("a", "a edited");
        $("#header").click();
/*
    ну да
    можно кликнуть и на $("#header")
    а можно и на чем-то, чем мы уже пользуемся - чтоб меньшее количество селекторов использовать
    нам еще нужно - чтоб при клике на элементе - ничего кроме смены фокуса не происходило

    нам подойдет для этих целей $("#new-todo")

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

    и для этой переменной, и для переменной для списка тасок - используй модификатор доступа public
    вполне возможно - что это тоже пригодится - не только внутри методов пейджа
    а и в тест-методах
*/