Untitled

public class TodoMVCTest {

    @Test
    public void testTaskManagement() {

        open("https://todomvc4tasj.herokuapp.com/#/");

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

            внизу приведу этот кусок еще раз
        */

        edit("2", "two");
        /*
            тут прикольно использовать тестовые данные как пояснения
            edit("2", "2 edited");
            дальше по коду  - будет понятнее - что за таска
        */
        delete("two");
        /*
            вот если бы это была единственная таска в списке
            то да, delete("two") - проверит операцию edit("2", "two");
            проверка должна касаться всех видимых тасок в списке

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

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

            и снова - смотри на следующую строку
            cancelEdit("1", "one"); - не проверяет результаты   delete("two");
            значит - после  delete("two"); - нужна проверка

            и еще
            не торопись удалять таски раньше времени
            ведь чем позже ты удалишь таску - тем меньшее их количество тебе понадобится для теста
            а значит - мы сэкономим время на создании тасок
            эффективность - очень важна
        */
        cancelEdit("1", "one");
        /*
            cancelEdit("1", "1 edit canceled"); - как вариант  - чтоб тестовые данные тоже играли роль пояснений
        */
        assertTasksAre("1", "3", "4");

        toggle("4");
        clearCompleted();
        /*
            однозначно - и complete и clearCompleted - можно проверить точнее
            если они будут не парой

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

            да и торопиться удалять еще одну таску - ни к чему)

            чуть ниже - будет понятнее как это лучше сделать
        */
        assertTasksAre("1", "3");
        counter("2");
        /*
            https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.sswzyp7qkm9o
            и в ревью к прошлой работе - про термины для этой проверки тоже было, перечитай
            еще - мы проветяем количество=число активных тасок, потому для более понятного кода - нужен для метода - именно числовой параметр

            assertItemsLeft(2) - такой вызов будет много рассказывать о себе
            и что проверка
            и что она проверяет
            и что принимает на вход
        */

        toggleAll();
        assertTasksAre("1", "3");

        filter("Active");
        /*
            ну да)

            закомплитил все таски
            проверил тексты = проверил логику = таски на all отображаются вне зависимости от их статуса

            перешел на Active
            и ....
            тут должна быть проверка - состояния списка тасок = в списке нет видимых тасок

            тут мы бы проверили и фильтрацию максимально точно (было = одно состояние списка, стало = другое, и оно соответствует фильтру)
            и допроверим закомпличивание

            теперь про complete & clear completed
            мы могли перейти на Active фильтр сразу после complete
            и точно также - после перехода на Active фильтр
            мы бы допроверили закомпличивание  + фильтрацию проверили точно

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

            про реализацию метода filter - ниже будет еще)

        */
        add("2", "4");
        assertTasksAre("2", "4");
        /*
            а вот так не делай
            даже если уже таски "2", которую ранее добавлял, уже нету

            не добавляй в том же сценарии одноименные таски

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


            ну и опять)
            зачем тебе 2 таски сразу? )
        */

        edit("2", "two");
        delete("two");
        toggle("4");
        /*
            все это - уже покрыто на all

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

            skoke coverage = покріваем только высокоприоритетное и ТОЛЬКО один раз (на одном контексте)

            ниже про smoke - снова приведу кусочек текста

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

            да и дальше - filter("Completed"); не проверяет предыдущее
            потому - нужна проверка
        */

        filter("Completed");
        assertTasksAre("1", "3", "4");

        edit("1", "one");
        delete("one");
        /*
            это мы уже покрывали на других фильтрах
        */
        toggle("4");
        /*
            где проверка после reopen?

            я бы прокомментировала - что это reopen
        */
        clearCompleted();
        /*
            вот тут как раз - хорошее место для покрытия clearCompleted
            т к тут уже  - почти конец сценария
            да и состояние списка тасок после clearCompleted - на этом фильтре - сразу поменяется

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

            но в качестве основной - она не годится
        */

        counter("1");
        /*
            состояние счетчика items left - да, меняется при любом действии
            но - в принципе - даже если только счетчик не работает или не верно работает
            приложение все еще функционально

            потому приоритет этой фичи - не высокий

            за счет  того - что меняется его состояние постоянно
            состояние счетчика items left стоило покрыть
            но одного раза на весь этот сценарий - достаточно

            тоже было про это
            тоже повторю текст
        */
        filter("All");
        /*
            нужна проверка
        */
        toggleAll();
        clearCompleted();
        /*
            это - уже покрыто ранее, и не один раз
        */

        assertNoTasks();
    }
/*
    проанализируй - что где покрыто
    рекомендую работать с Use Cases List - отмечай покрытие, планируй его еще на уровне работы со списком

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

    не забывай про эффективность
        - не повторяемся (с добавлением таски так не получится, с остальным - получится)
        - используем неявные проверки через действия как можно более активно (потому - не торопись добавлять сразу несколько тасок)
        - откладываем удаление тасок (на важно каким способом) на конец сценария (так меньше придется создавать тасок - мы их не будет так тратить в процессе)
    а также
        - распределяй покрытые действия по разным фильрам - поравномернее
        чтобы можно было и такое вылавливатьеще на уровне такого теста - когда на одном из фильтров есть проблемы с выполнением операций над тасками
        - если не можешь проверить что-то с помощью неявной проверки, делай явную
        просто пропускать проверку нельзя - т к тест упал, а чтоб понять - что конкретно к этому привело - надо долго разбираться
*/
***************************************
    private void assertTasksAre(String... taskTexts) {
        tasks.filter(visible).shouldHave(exactTexts(taskTexts));
    }

    private void assertNoTasks() {
        tasks.shouldBe(empty);
    }
/*
    тут - или работай с отфильрованным списком - или с не отфильтрованным + добавь 2 метода для работы с отфильтрованным
    тоже было про это

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

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

     Посмотри видео Якова про это - https://drive.google.com/file/d/0B8hgIBw8-V-AdGxxU1R3enl1RzQ/view?ts=567ab8d7
*/
********************************
    private void edit (String oldValue, String newValue) {
    private void cancelEdit (String oldValue, String newValue) {
/*
    имена параметров

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

    old & new - хороший вариант чтоб показать было-стало

    получим - oldTaskText & newTaskText

    еще - посмотри на код этих методов
    отличий - немного
    делаем код более DRY

    реализуй метод xxx который будет возвращать SelenideElement = элемент
    в котором мы указали новый текст

    и потом будешь его переиспользовать как xxx(.....).pressEnter();

    подумай над именем метода
    чтоб оно отражало - что метод делает
    фактически - он лишь начинает/стартует редактирование
*/
***********************************
    private void filter (String filterName) {
        $$("#filters>li").find(exactText(filterName)).click();
    }
/*
    посмотри вот этот раздел
    https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.8bflixemdgfw

    примени знания оттуда

    а также - перечитай в FAQ - разделі по KISS и DRY принципам
*/
***************************************
    private void counter (String taskCount) {
        $("#todo-count").shouldHave(text(taskCount));
    }
/*
    Про имя метода и тип параметра - писала выше

    по реализации

    уточни элемент и уточни кондишен

    т к при такой реализации - если будешь проверять для "1"
    а в счетчике - "10" - то проверка пройдет
*/
*********************************
/*
    про использование неявных проверок через действие
          вариант 1
          add("task1"");
          edit("task1", "task1 edited");
          delete("task1 edited");

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

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

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

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

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

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

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

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

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

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

*/

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

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

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

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

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