public class TodoMVCUseCasesTest {
    /*
        вот это уточнение про UseCases - мало что нам дает

        мы и в прошлый раз UseCases тестировали)
        и вообще - что кроме UseCases можно тестировать? )

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

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

        и так далее

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

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


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

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

   All
    add * 5
    edit * 2
    delete * 2
    complete * 2
    complete all * 2
    activate
    activate all
    clear completed

    items left counter * 6

    ->Completed * 2
    ->Active * 2

   Completed
    add * 2
    delete
    complete all * 2
    activate
    activate all
    clear completed * 2

    items left counter * 2

    ->All
    ->Active * 2

   Active
     add
     complete
     complete all

     items left counter * 2

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

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

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

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

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

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

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

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

      И в самом тексте задания говорилось про efficiency of “smoke approach”

            что за efficiency of “smoke approach”
            нам нужен быстрый, точный фидбек о высокоприоритетных операциях
            быстрый = значит не нужно делать ни одного лишнего движения,
            не тратить на второстепенное время
            точный - значит по-прежнему проверять каждое действие сразу

            нам нужен быстрый результат.
            мы не можем себе позволить бездумно повторять действия, уже ранее покрытые

    дальше читаем задание
    use “implicit checks” when possible, like:
          add(“1”)
          edit(“1”, “xyz”)  // here we implicitly check that “1” task was created. Otherwise we could not edit it.

        что имеется в виду

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

        пример - в задании приведен
        после добавления таски 1 мы не делали assertTasks
        мы делали edit(“1”
        если бы возникли проблемы с edit(“1” - то это значит, что предыдущая операция работала не верно

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

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

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

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

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

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

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

        как еще можно повысить эффективность
        отложить удаление тасок на самый конец теста
        а перед этим над добавленными тасками выполнить разные другие действия
        чтоб не приходилось лишний раз создавать таски
        этот тест можно написать, создавая таски дважды, по одной штуке)
*/
**********************************************
    public void clickButton(String buttonName){
        filters.find(exactText(buttonName)).click();
    }
/*
    даже для такой организации метода - имя плохо поясняет  - что мы делаем
    пока не заглянешь в метод - не поймешь

    вариант switchToFilter(String name) - был бы понагляднее и поточнее

    но - и это не лучший вариант)

    почитай вот это
    https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.8bflixemdgfw

    и вообще про DRY & KISS - в нашем FAQ и при необходимости - во внешних источниках)

    и реализуй переходы на фильтры - более KISS
*/
*************************************************
    public void counter(String count){
        $("#todo-count").shouldHave(exactText(count));
    }
/*
    что мы делаем
    мы проверяем
    https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.sswzyp7qkm9o

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

    а вот куски фразы items left или items left - проверять уже не нужно вовсе
    т к это уже больше не к логике, а к оформлению
    а мы концентрируемся на функциональных проверках
    в видео
    https://drive.google.com/file/d/0B8hgIBw8-V-AUDhxWDg1YmYxM3c/view?usp=sharing
    примерно на  58-ой минуте было про это

    и в реализации проверки тогда придется уточнить - селектор
*/
**********************************
    public void editCompletedTask(String oldName, String newName){
        tasks.find(exactText(oldName)).doubleClick();
        $(".completed").find(".edit").setValue(newName).pressEnter();
    }
/*
    примени этот метод к второй закомпличеной таске в списке
    получилось отредактировать?
    ))
    этот  метод реализован не верно

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

    так мы раздуем наше решение

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

    грамотнее реализовать метод edit
    который сможет откорректировать таску с любым статусом
*/

    public void editActiveTask(String oldName, String newName){
        tasks.find(exactText(oldName)).doubleClick();
        $(".editing").find(".edit").setValue(newName).pressEnter();
    }
/*
    попробуй применить метод к закомпличеной таске
    он будет работать)

    так зачем тогда в имени метода писать про Active?
    да и в прошлый раз мы уже определились - что для имен методов-действий - не нужно использовать Task
    т к тут - все действия выполняются над тасками
    вот у нас уже были имена - add, delete, toggle, ....

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

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

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

    oldTaskText & newTaskText - будет ок
*/