public class WithReportedScreenshotsPerTest {

 ...
   File screenshot = Screenshots.getScreenShotAsFile();
/*
    Наверное, у тебя в проекте какая-то не очень новая версия selenide используется

    посмотри раздел в faq http://joxi.ru/BA0p30gsB36jLA
    https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#heading=h.9ginsk3d52i

    сейчас вместо getScreenShotAsFile() - другие методы

    на изменениях не настаиваю, просто чтоб в курсе ты была)
*/
*************************************************
TodoMcvFullCoverageTest

/*
    В имя тест-класса не стоит выносить информацию о покрытии

    Это важная информация, но это и меняющаяся со временем информация )

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

    Эту информацию - о покрытии - если и помечают как-то
    то используют категории
    расшарила тебе видео на эту тему, не надо ничего реализовывать по ним
    просто для понимания вопроса)
    https://drive.google.com/file/d/0B8hgIBw8-V-AbE1qV1JCMklwX2c/view?usp=sharing
    https://drive.google.com/file/d/0B8hgIBw8-V-AMXYyeHNIOVhUVGM/view?usp=sharing

    В рамках этой работы - просто из имени тест-класса - убери FullCoverage

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

AtTodoMVCWithClearDataAfterEachTest

/*
    Ты знаешь, это не очень хорошая идея - вынести степ-методы в предка тест-класса

    Согласна, тогда код самого тест-класса - почище получается)

    Но, все же, это не верно

    есть такой Single Responsibility Principle
    почитай про него

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

    вот у предка тест-класса AtTodoMVCWithClearDataAfterEachTest - задача
    открывать урл перед тестом и чистить данные после теста
    это все)
    и именно это мы описали в его имени

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

    а степ-методы, и методы-проверки - это уже логика действий тестов
    и это - если уже выносить - то в пейдж (или пейджи)

    В рамках этой задачи = такого не требовалось
    Только вот это
    https://docs.google.com/document/d/1tr6pz9tPawGV8bHW_fCXEx2P8bHEaNWvM55H6eQD_dA/edit#heading=h.tg17u4svwj28

    Так что - смотри сама)
    Или верни в тест-класс эти методы  (степ-методы, и методы-проверки )
    или реализуй пейджа
    как тебе удобнее

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

import static ua.net.ItLabs.separate.pageModules.TodoMvcModules.assertTasks;
/*
    ты в этом решении - используешь метод из другого решения - уже из пейджа
*/

    public void assertVisible(String... taskTexts) {
        tasks.filter(visible).shouldHave(exactTexts(taskTexts));
    }

    public void assertNoTasks() {
        tasks.shouldBe(empty);
    }
/*
    А в этом решении - есть 2 вот такиз метода
*/
/*
    что мы в итоге имеем

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

    используем методы
    2 - для не отфильтрованного по visible списка - assertTasks и assertNoTasks()
    1 - для отфильтрованного  по visible списка assertVisible

    логика имени assertVisible - не такая, как у предідущих ассертов
    не известно - что работаем именно с тасками
    assertVisibleTasks - корректнее

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

    ок
    одно из возможных решений

    но, тогда не ясно, почему нету метода assertNoVisibleTasks()
    для проверки ситуации - когда видимых тасок нет, но вообще они есть

    Кстати, в применении - 4 таких метода будут гораздо сложнее, чем 2
    (когда мы всегда проверяем отфильтрованный по visible список)
    Т к важно будет - приенять их обдуманно

    Например, мы на Active фильтре работаем
    допустим, у нас нету невидимых тасок и мы сейчас используем более точную проверку assertTasks
    вроде бы - все ок, мы же хотим быть максимально точными
    затем - чуть меняем сценарий - на сколько-то строк выше
    и на момент проверки - у нас уже есть невидимая таска
    и вот - результат - assertTasks нормально не работает....
    и надо анализировать сценарий в целом и искать источник проблем

    значит - чтобы избежать таких проблем - применяем правило
    assertTasks и assertNoTasks() - используем на All фильтре
    assertVisibleTasks и assertNoVisibleTasks() - на Active & Completed фильтрах
    да, выше описанных проблем избежим
    но - надо это правило неписанное знать и безошибочно применять
    т е - тоже - вариант не очень, но уже более стабильный
    так что - если все же оставишь 4 проверки - придется это учесть в коде)

    Вывод - за все надо платить)
    оставишь 4 проверки - в написании и поддержке тестов сложнее
    оставишь 2 проверки - не так точно...
*/
************************************

    public void add(String text) {
    public void edit(String fromText, String toText) {
    public void delete(String taskText) {
    public void toggle(String taskText) {
    public void assertVisible(String... taskTexts) {

/*
    кажется, догадалась, почему в имени assertVisible нет слова Tasks
    т к у всех методов имена подравняла

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

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

    по поводу имен параметров
    обозначить текст таски как taskText - хорошая идея
    надо во всех методах поправить имена параметров
    ведь обозначаем - именно текст таски
    вот и будем применять один термин
    taskText, taskTexts, fromTaskText, toTaskText

*/
****************************************
  @Step
    public void add(String text) {
        $("#new-todo").setValue(text).pressEnter();
    }
/*
    вот тут есть пример реализации метода add, с помощью которого можно добавить несколько тасок
    код при вызове такого метода может стать попроще - если надо добавить сразу несколько тасок

  https://docs.google.com/document/d/1tr6pz9tPawGV8bHW_fCXEx2P8bHEaNWvM55H6eQD_dA/edit#heading=h.tg17u4svwj28
*/

*****************************************
@Step
    public void edit(String fromText, String toText) {
        tasks.find(exactText(fromText)).find("label").doubleClick();
        $(".editing>.edit").setValue(toText).pressEnter();
    }
/*
    в более старших версиях Selenide уже не надо именно на label даблкликать
    можно уже просто на таске
    тоже больше к сведению, можешь не париться с версиями

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

    такой вариант  - лучше - т к
    у нас будет меньше независимых селекторов в коде (меньше исправлять и проще понимать)
    у нас код будет нагляднее - т к сразу яснее - с чем работаем
    при падении теста  на строке $(".editing>.edit") - текст ошибки нам мало поможет
    а на строке - tasks.findBy(cssClass("editing")).find(".edit") - поможет наверняка
    т к сама ошибка - будет точнее
    вот тут приводился код , который нам нужен
    https://docs.google.com/document/d/1tr6pz9tPawGV8bHW_fCXEx2P8bHEaNWvM55H6eQD_dA/edit#heading=h.qp6awiu5k68k


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

    @Test
    public void testAtAllFilter() {

        add("1");
        add("2");
        add("3");
        add("4");
        /*
            вот эти 4 строки получится свернуть в одну - если дореализуешь метод add

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

        // Edit task
        /*
            как считаешь - комментарий хоть что-то пояснил?
            не держи бесполезных комментариев )
            вообще на этот предмет код просмотри
        */
        edit("1", "1.edited");
        assertTasks("1.edited", "2", "3", "4");

        // Delete task
        delete("1.edited");
        assertTasks("2", "3", "4");

        // toggle and de-toggle
        /*
            toggle = переключить
            de-toggle = рас-переключить? ))

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

            используй соответствующий комментарий перед своим вызовом тугла
        */
        toggle("4");
        toggle("2");
        /*
            а зачем 2 таски комплитить?
            для проверки закомпличивания - достаточно одну закомплитить)
        */
        filterAll();
        assertItemsLeft(1);
        /*
            вот это не поняла ...
            мы же вроде на олле и есть
            зачем filterAll();

            проверка assertItemsLeft(1); - слабовата, мне кажется
            слишком косвенная

            можно было бы тут
                проверить тексты тасок = на олле таски видны вне зависимости от статуса
                перейти на active
                проверить тексты тасок = переход на фильтр проверили + убедились в закомпличености
                вернулись на all
                проверили тексты тасок = переход на фильтр проверили

             а есть совет - как реализовать эффективнее
             https://docs.google.com/document/d/1tr6pz9tPawGV8bHW_fCXEx2P8bHEaNWvM55H6eQD_dA/edit#heading=h.x1p9b4vm5pun

             тогда - если этот совет использовать
               закомплитили 2 таски
               переоткрыли одну таску
               clearCompleted()
               проверили тексты = переоткрытая осталась, закомпличеная ушла
          */
        toggle("4");
        toggle("2");
        assertVisible("2", "3", "4");

        // toggle and clear
        /*
            все же complete all & clear
        */
        toggleAll();
        clearCompleted();
        /*
            на момент complete all & clear - разумно приходить с одной, максимум - двумя тасками
            бОльшего количества для проверки complete all & clear - нам не надо)

            проверки не хватает)

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

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

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

*********************************************

@Test
    public void testAtActiveFilter(){

        ...

        // complete
        toggle("3");
        assertItemsLeft(2);
        /*
            Мы же на Active фильтре
            если проверим тессты видимых тасок - проверка получится гораздо точнее
            а потом - можно и счетчик активных тасок проверить

            когда идут 2 проверки подряд - первой делай более высокоприоритетную
            тогда - даже если тест упадет на низкоприоритетной
            у тебя останется фидбек по высокоприоритетной проверке
        */

        // complete all
        toggleAll();
        assertItemsLeft(0);
        filterCompleted();
        assertTasks("1.editedOnActive", "3", "4");
        /*
            тут - можно никуда не переходить
            было - в списке несколько видимых тасок
            закомплитили все
            стало - в списке нет видимых тасок
            все)
            мы проверили
        */

        // reopen all
        toggleAll();
        /*
            сейчас эту операцию мы проверяем на комплитеде
            хотя тест = AtActiveFilter

            если ранее не переходить на Completed фильтр
            то reopen all - проверишь  AtActiveFilter
            заодно и допроверишь закомпличивание)

            переоткрыли = ранее закомпличеные таски стали видимыми
            все)
            далее - остального вообще не надо)
  ...

/*
    вот тут есть вариант - как реализовать тест-методы поэффективнее
    https://docs.google.com/document/d/1tr6pz9tPawGV8bHW_fCXEx2P8bHEaNWvM55H6eQD_dA/edit#heading=h.64cp8bd2pyhg

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

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

    к третьему тест-методу - попробуй применить выше описанное)
*/