Untitled

http://joxi.ru/Vrwqg81HKB4ZN2

/*
    это по пути

    пока пекеджи не особенно четко говорят - где какая работа

    эта работа - это уже не вторая версия feature тестов
    а новая - full coverage

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

    пройдет еще немного времени - и тебе будет сяжело сориентироваться


    разложи решения разных добашек по пекеджам так, чтоб на одном уровне вложенности были пекеджи = значения одной категории
    типа такого
    homeworks
        hw1
            v1
            v2
        hw2
            v1
            v2
            ...
        ...
*/
****************************
    @Before
    public void openPage() {
        if (!($("#new-todo").is(visible))) {
            open("https://todomvc4tasj.herokuapp.com/");
        } else {
            refresh();
        }
    }

    дуже довго чекає запуску сторінки (більше хвилини)
/*
    Я такое смогла увидеть на твоем коде - когда опрерировала версией Selenide 3.6

    ФФ использую - 47,0,1

    Я вот после перехода на Selenide 3.11 - таких проблем не стало


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

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

    url() - возвращает урл текущей открытой страницы

    refresh(); - нам тут еще рано делать
    он нужен только после работы с локалсториджем
    кстати, скорее всего, проблема уйдет вот эта = тести з методом add не проходять, лишається назва таски в полі #new-todo
    про это отдельно напишу
    но уже после таких исправлений в файрфоксе может перестать проявляться эта ошибка

    и еще - если вызывать гивен-метод в каждом из тест-методов
    то нам не нужен @Before -метод
    можно этот if - перенести внутрь гивена

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

    заодно и иерархию упростим
*/
*********************
тести з методом add не проходять, лишається назва таски в полі #new-todo
/*
    тут "ноги растут" из проблем самого приложения нашего

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

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

    в хроме - который чуть побыстрее - такая ошибка проявляется чаще)

    теперь про что делать)

    начнем с того - что если в твоей текущей версии все ок(уже с изменениями, описанными выше)
    то и ок)

    проверку, что Яков рекомендовал -  $("#new-todo").shouldBe(enabled)
    ты как раз встроила

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

    хотя - в такой версии, что ты реализовала - должно быть достаточно)
    если убрать лишний рефреш)

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

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

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

*/
**********************************
2. @Test
    public void testCompleteOnAll() {

        given("1");

        //complete
        toggle("1");
        assertTasksAre("1");
        assertItemsLeft(0);
    }

    чи можна це вважати достньою перевіркою?
/*
    когда будут тесты и лля переходов с фильтра на фильтр

    в варианте
    дано = активные и закоимличеные таски на таком-то фильтре

    делаем = переход на такой-то фильтр

    проверяем список тасок и итемс лефт

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

*/
******************************
 given(aTask("1", State.COMPLETED), aTask("2", State.COMPLETED));
 filterCompleted();
/*
    насчет COMPLETED вместо State.COMPLETED
    то просто используй import static для State.COMPLETED и State.ACTIVE
    и все)

    думаю, на третий вопрос твой я тоже ответила

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

    не
    given(aTask("1", State.COMPLETED), aTask("2", State.COMPLETED));
    filterCompleted();
    а
    givenAtCompleted(aTask("1", State.COMPLETED), aTask("2", State.COMPLETED));

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

    это не DRY

    и это в поддержке - всегда ведет к проблемам и потерям - соответственно

    пример - в одном алгоритме что-то подправили
    а в другом  - нет

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

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

    чтоб так делать - надо уметь из State state, String... taskTexts
    получить Task... tasks

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

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

        написать код в одну строчку
        given(xxx(taskType, 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)

*/
****************************

http://joxi.ru/EA4k7zEUDdvKE2

/*
    код внутри гивен-метода - можно упростить

    давай посмотрим на собираемую строку
    http://joxi.ru/Q2KpJYOs9zy0zA
    вот эти кусочки - {....}
    это как раз описание таски
    и логично это делать единожды
    я бы даже это поручила самому классу Task )

    если реализовать toString() в классе Task
    то "some text" + task = даст нам строку "some text" - продолженную тем, что возвращает toString() класса Task)
    все классы  - это потомки Object, у которого реализован toString()
    этот метод отвечает за преобразование объекта к строке, и это часто можно использовать очень эффективно

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

    так логика упростится

    насчет запятой между {....}

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

    мне нравится - с использованием String.join(...)

    Given - String.join()
    Нравится реализация метода)

        Красивее может стать только за счет использования String.join(",", ...)

        Есть об этов в прошлом ревью

        если вместо StringBuilder jsContent
        создать List<String> jsContent
        и в цикле собирать в этот список тесты объектов task
        то внутри цикла - можно будет вообще не заботиться о добавлении запятой
        а уже когда строку собираешь - сможешь применить String.join(",", jsContent)
        такая операция даст строку, в которой все ее элементы будут идти через запятую
        так код станет еще лаконичнее

        Настаивать на этих изменениях не буду, советую попробовать)
        https://docs.oracle.com/javase/8/docs/api/java/lang/String.html
        http://joxi.ru/V2VBQLqf0ZW692 - фактически, вызываем второй из этих методов
        (переменную типа List<String> тут можно передать в качестве второго параметра)

        https://habrahabr.ru/post/260767/
        http://javarevisited.blogspot.com/2016/06/10-examples-of-joining-string-in-java-8.html

     важно - гивен-метод должен ок работать и при вызове given()
     в результате такого вызова - должен быть пустой список тасок
*/
*****************************************
/*
    В этом задании - оставь и е2е тест
    и дополни его фиче-тестами

    оптимизировать покрытие не обязательно
    но можно

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

    В следующий раз - приведи и тест-план и код

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

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


*/
****************************
private enum State
/*
    Я бы это enum назвала TaskState все же
*/