Untitled

/*

    вначале - напишу общие моменты
    далее - прокомментирую код

     Мы реализуем е2е сценарий для smoke покрытия
        это значит - что достаточно покрыть высокоприоритетный юз кейс лишь единожды, на одном из контекстов

        т е - единожды покрыли complete на all фильтре - все, этого достаточно

        конечно, с добавлением таски так не получится )
        тоже - правильно считай операции)
        add("1","2","3"); - это 3 операции
        потому - нету смысла стараться добавлять все необходимые таски за один вызов метода add

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

        задача smoke покрытия - быстро дать нам фидбек = все высокоприоритетные операции работают
        не -  все высокоприоритетные операции работают на всех контекстах
        а именно вот так - что они работоспособны

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

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

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

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

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

                     Так вот - низкоприоритетные вещи - в smoke-тесте не нужно покрывать.
                     Чтобы оставить smoke тест эффективным

                     А вот Reopen All - уже имеет приоритет пониже - т к реже будет использоваться, чем тот же reopen
                     потому - reopen - стоит покрыть, а Reopen All - уже не стоит

                     Проверку счетчика Items left - стоит покрыть лишь единожды.
                     В общем-то - это не высокоприоритетная штука.
                     Т к даже если это не будет работать - приложение будет все равно функционально.
                     С другой стороны, на состояние этого счетчика влияет любая выполненная операция.
                     Ввиду этого - в рамках е2е покроем его лишь единожды.

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

              вариант 1
              add("task1"");
              edit("task1", "task1 edited");
              delete("task1 edited");

              вариант 2
              add("task1", "task2");
              edit("task2", "task2 edited");
              delete("task2 edited");

           Вариант 1 = правильное использование таких проверок через действие

           Вариант2 = не правильное использование
           Т к последующие действия не проверяют состояние ВСЕХ тасок в списке

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

           Также не забывай - после каждого действия должна быть выполнена проверка
           Сразу
           Не получается использовать неявную проверку через следующее действие - используй явную
           Но - действие должно быть обязательно проверено сразу

*/

public class ToDoMVCTest {

    @Test
    public void tasksLifeCycle() {
        open("https://todomvc4tasj.herokuapp.com/");

        add("1","2","3");
        assertTasksAre("1","2","3");
        /*
            добавляя сразу несколько тасок -
            ты лишаешь себя возможности использовать неявные проверки через действия

            на самом деле  - для следующей операции - нужна лишь одна таска
            вот советую только ее и добавить
        */

        edit("1","1e");
        /*
            направление верное )
            еще более наглядно - edit("1","1 edited");
            далее по тексту - будет яснее - что происходило с таской
        */
        assertTasksAre("1e","2","3");

        toggle("2");
        toggle("3");
        /*
            после каждой операции - нужна проверка)
            и - достаточно единожды покрыть complete
            в рамках smoke покрытия этого достаточно

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

                первое хорошее - мы сэкономили на проверках
                    редактирование - проверило добавление
                    закомпличивание - проверило редактирование
                второе хорошее - мы проверили такие моменты в тестовой логике
                    таски на all фильтре отображаются вне зависимомти от статуса
                    мы максимально точно проверили переход на active
                        (т к состояние списка тасок  поменялось - значит фильтеринг работает
                        т к состояние списка тасок верное - значит фильтеринг работает верно)
                    мы допроверили закомпличивание таски - в проверке после перехода на active
        */
        assertTasksAre("1e","2","3");

        filter("completed");
        /*
            почитай вот это
            https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.8bflixemdgfw

            и вообще - про KISS principle (в faq - есть про это больше))
        */
        assertTasksAre("","2","3");
        /*
            ага, ты так выкрутилась)

            ты увидела вот это - http://joxi.ru/l2ZNaR0F83gJv2 ?

            посмотри вот это
            https://drive.google.com/file/d/0B8hgIBw8-V-AdGxxU1R3enl1RzQ/view?usp=sharing

            мы можем быть максимально точными и держать 4 проверки
                2 -
                    в списке = такси с такими-то текстами
                    в списке = пусто
                и еще 2 -
                    в отфильтрованном по visible списке = таски с такими-то текстами
                    в отфильтрованном по visible списке = пусто
                И за точность будем платить  тем - что надо думать - когда какую проверку вызвать правильнее
                и если это делать бездумно - то при небольших изменениях сценариев - могут тесты падать на проверках,
                или второй вариант - не будем нормально пользоваться полученной точностью...

                мы можем исходить из того, что ошибку, когда невидимые таски копятся в списке - мы тестим на более низком уровне,
                и на UI уровне - нам не нужно до этого уточняться. Поэтому - мы будем держать всего 2 проверки
                      в отфильтрованном по visible списке = таски с такими-то текстами
                      в отфильтрованном по visible списке = пусто
                В таком случае - каждый раз понятно - какую проверку вызывать - получаем более KISS картину
                правда, платим за это точностью) Но - возможно - если мы уже отдельно это в тестах покрыли -
                что у нас не копятся невидимые таски - так мы и не платим ) И - тогда - все проще в написании тестов,
                и в их сопровождении.
                Тогда - поскольку обе проверки реализованы одинаково и других нету - можно из имен проверок скрыть этот нюанс
                и назвать их assertTasks и assertNoTasks (хотя в них работаем с отфильтрованным по visible списком тасок)


        */
        toggle("2");
        clearCompleted();
        /*
            вот это решение - покрыть reopen & clear completed
            на completed фильтре - очень разумное)

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

                после clear completed - тоже нужна проверка
        */

        filter("active");
        /*
            тут - 2 таски в списке
            потому delete("2") - не проверит состояние списка в целом

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

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

    All
        add *3
        edit
        complete *2

    Completed
        reopen
        clear complete

    Active
        delete

    что мы не сделали
        cancel edit
        complete all
        filter All

    что сделали лишний раз
        add - можно єто сделать лишь дважды
        complete - достаточно покрыть лишь единожды

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

*/
****************************************
    public void edit(String taskText, String newTaskText) {

        tasks.findBy(exactText(taskText)).doubleClick();
        $(".edit").setValue(newTaskText).pressEnter();

    }
/*
    Про имена параметров - верно, что используешь для текста таски - taskText
     для обозначения было-стало - хорошо использовать old & new, from & to
     oldTaskText & newTaskText
     fromTaskText & newTaskText

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

     этот элемент .edit - он внутренний элемент для редактирвуемой таски
     оттолкнись от tasks, получи редактируемую таску, и затем - получи внутренний элемент .edit
     http://joxi.ru/v29WjP9hGkx9pr
*/
**********************************************
    public void filter(String filterName) {
        $("a[href*='"+filterName+"']").click();
    }
/*
    про реализацию переходов по фильтрам - выше писала

    по самой операции
    есть такой вариант - более наглядный
    $(By.linkText(...))
*/