вопросы - https://github.com/AleksanderPopov/automician_course/blob/master/questions_and_review/13_questions.txt
========================================================================================================================
1. "значит - ресурсов на этом сервере - должно быть столько - что даже если все гигабайты хлама будут нагенерены
    одновремено
    ресурсов должно хватать
    если это не так - это проблема серьезная)
    и просто вот такими поисками ресурсов - ее глупо решать
    время специалиста, который будет вот так гоняться за ресурсами - стоит дороже самих ресурсов)

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

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

                    я не понимаю, ты считаешь что

                    mvn clean test - это окей

                    а

                    mvn test clean - это лишнее время которое мы тратим на прогон тестов?

                    ты никогда не чистила target ПОСЛЕ тестов, но всегда чистила ДО ? как то задом-наперед получается...
                    мы сначало создаем себе проблемы на будущее, а когда возвращаемся к тесту перед тем как ранить его
                    начинаем разгребать старый мусор?
/*
    у меня вопрос - не к вызову clean
    а к очистке(частичной) - во время выполнения  test
    если мы в методах по приаттачиванию скриншотов будем их удалять - это мы будем делать в рамках test
    вот это я считаю пустой тратой времени

    к очистке с помощью clean - вопросов нет

    что до варианта - mvn test clean
    да, я такой вариант никогда не использовала

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

    пример
        Настраиваем Job Jenkins
        с использованием варианта mvn test clean
        и затем - настраиваем Post Build Action
        которое публикует алюр-репорт

        я думаю - будут проблемы)
        потому что clean - уже все почистил)

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

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

                    не чистить - зло. потому что файлы копятся, место кончается, memory leak - привет.

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

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

                    я буду чистить после рана, т.к. считаю это самым эффективным и правильным вариантом)

                    чет задела меня эта тема, я погуглил, и нашел такое решение, как maven-clean-plugin.

                    теперь он автоматически, всегда, делает clean фазу после site фазы (т.е. сначала генерируется репорт,
                    а потом чистятся скрины всякие, pageSource и т.п.)
/*
    вот!
    верно
    clean нужен после site фазы

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

    про задела тема - ну ок
    я - не истина в последней инстанции)
    спорить - не буду.
        Я осталась при своем мнении и буду юзать clean test вариант. Меня в нем все устраивает)
        После выполнения test - папка target - это еще не мусор по моему мнению)
        Пока мы не закончили возню с публикацией отчетов - это не мусор
        После того - ну да, можно потратить силы и удалить вот это все лишнее. Вопрос - нужно ли
        Почему - писала в прошлые разы.
        Сейчас я для сравнительно крупных проектов(не касающихся курса) - юзаю gradle - как более гибкий инструмент
        Там тоже по умолчанию - задача cleanTest - выполняется до запуска тестов )
        Хотя конечно настроить можно что угодно)

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

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

                    mvn clean test site -> mvn test site

                    и не надо никаких post-build-actions.

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

    кстати - ты знаешь - что до site  дело не дойдет, если на фазе test тесты упадут
    если у нас была команда - mvn test site
    ?

    да и при настройке Job в Jenkins - мы не указываем фазу site
    Просто используем Post-build Action = publish allure report
*/
========================================================================================================================
2. "    про селенидовский рефреш - первое что делай - когда вопрос возникает - смотри исходники
            вот посмотри например на код open  - https://github.com/codeborne/selenide/blob/master/src/main/java/com/codeborne/selenide/impl/Navigator.java
            там куча вариантов
            в том числе - и странички, открываемые локально

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

                >>>>>>>> я как раз смотрел, и там же и увидел что нет такого метода как refresh(),
                        а есть скрытый navigate(url), и спросил, может ты знаешь почему так)

                        странное решение, учитывая что как вот показывает практика оно не особо
                        работает в рядовых кейсах
    /*
        это не рядовой кейс)
        т к вот эти странички - по фильтрам которые - ведут себя ... не совсем как разные странички с разными урлами)
        тут мы еще и на особенности реализации этой версии todoMVC наступили)
        так что случай не совсем рядовой)

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

        но мы ж сразу наворачиваем)
        за что и заплатили)
    */"

            >>>>>>>> не вижу ничего "не-рядового" в текущем кейсе... у меня проект - single-page-application,
                    и там всякие обернутые driver.navigateTo() не прокатят вообще, а нужен именно нормальный
                    человеческий рефреш)

                    может быть в приложении где странички все сами по себе, и никакой связи между ними нет
                    текущая реализация в selenide может и прокатила бы, но это не оправдывает то, что метод
                    refresh() не вызывает реальный рефреш страницы в браузере.

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

    почему такая реализация у рефреша в Selenide - я высказала гипотезу
    думаю, она верна)
    но на 100% не уверена, конечно

    у меня недостаточно оснований, чтоб утварждать - что метод refresh в selenide делает что-то другое)
    в том смысле, что я бы не стала на этом настаивать - в споре с автором Selenide, например)

    хочется бОльшей ясности - это не ко мне, это к Солнцеву
*/
========================================================================================================================
3. "            >>>>>>>> я переделал, можно теперь вот так вызывать

                        AllurePublisher.publishNow().screen();

                        AllurePublisher.publishNow().pageSource();

                        AllurePublisher.publishNow().screenAndSource();

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

                        AllurePublisher.publishScreenAndSource();

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

                        ну вот чет просто мне показалось что так будет красиво и просто вншне)
    /*
        Не)
        я предлагала тебе вариант покрасивее)

        в моем варианте - каждый класс отвечал за свое
        Твое решение - нарушает Single Responsibility Principle

        получился более сложный вариант
        советую переделать

        скажем так, настаивать не стану в категорической форме
        но и не жди от меня - что я соглашусь - что текущее решение - красивое

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

        в общем - делать или нет - на твое усмотрение )
        мое мнение ты понял)

        Не факт, что Яков согласился бы со мной или с тобой)
        Он тоже фанат Single Responsibility Principle )"

            >>>>>>>>>> SRP это хорошо, но если разделить существующий класс на отдельный класс-рул, который
                    может принимать сколько угодно классов-аттачей и просто когда нужно вызывать их методы
                    attach() грубо говоря, то в случае с selenide не получится делать один вызов screenshot()
                    и брать из его и скрин, и html. потому что это будут разные классы, например ScreenAttacher
                    PageSourceAttacher, или чет такое, и если передать их как параметры рулу, то он будет просто
                    вызывать методы .attach() у всех его объектов-параметров по очереди, а то что два из них
                    связаны из за selenide - это уже как бы не его проблемы.

                    в такой ситуации проще было бы попросить Солнцева разделить метод screenshot() на
                    screenshot() и pageSource(), тогда можно было бы сделать через rule-управляющего, и
                    его классы-аттачеры-параметры )

                    ну и конечно можно забить на то что будет в 2 раза больше файлов и делать скриншоты дважды,
                    один раз для того чтоб вытащить .png, второй раз для того чтоб вытащить .html =)
/*
    Не соглашусь с тобой - что в случае с selenide не получится делать один вызов screenshot() и брать из его и скрин, и html
    Когда я расписывала предлагаемую схему - я про это писала

    Ну то такое уже - не обязательная программа

    Текущая версия AllurePublisher - стала лучше предыдущей)
*/
========================================================================================================================
4. "    public static class Builder {
        ...
            public GivenHelper atAllFilter() {
                this.filter = Filter.ALL;
                return new GivenHelper(this);
            }

            public GivenHelper atActiveFilter() {
                this.filter = Filter.ACTIVE;
                return new GivenHelper(this);
            }

            public GivenHelper atCompletedFilter() {
                this.filter = Filter.COMPLETED;
                return new GivenHelper(this);
            }
    /*
        ну да, оно собразнительно выкинуть из цепочки вызовов build )
        но тогда - кто не в теме может теоретически - запутаться

        ведь согласно этого паттерна
        все методы кроме build()
        просто формируют пул свойств строящегося объекта
        и только  build() - строит сам объект

        при таком варианте - мы налагаем ограничения на порядок вызовов методов
        которые формируют пул свойств - мы должны вызвать at....Filter()
        причем последним

        для Builder Pattern
        если фильтр = обязательный параметр
            то это должен быть параметр конструктора билдера
            а раз мы не хотим светить вовне классом
            то тогда
                у конструктора билдера = параметр Filter filter
                у класса GivenHelper - 3 метода givenAt....
                которые будут вызывать конструктор с нужным параметром

        не настаиваю на изменениях
        твой вариант - не канонический)"

            >>>>>>>> да я знаю что не соблюдаю правила builder-pattern, сделал для читабельности,
                    пожертвовав при этом самим паттерном так сказать, и ограничением в виде применения
                    фильтра в конце)

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

                    не факт кстати что прям повысил до небес, по факту убрал одну строку

                    given().
                            .activeTask("1")
                            .atCompletedFilter()
                            .prepare();

                    given().
                            .activeTask("2")
                            .atCompletedFilter();
/*
    Я за более четкое соблюдение паттернов)

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

    по-прежнему - не буду настаивать на изменениях
*/
========================================================================================================================
5. "*/
        private String doJsonfromList(List<Task> tasks) {
            List<String> lsTasks = new ArrayList<String> ();

            for (Task task:tasks) {
                lsTasks.add("{'completed':" + task.type.lsValue + ",'title':'" + task.name + "'}");
            }

            return String.join(", ", lsTasks);
        }
    /*
        ну да, можно при конкатенации строк еще concat применить для скорости
        ну то уже детали
        http://stackoverflow.com/questions/47605/string-concatenation-concat-vs-operator

        твой вариант тоже ок)"

                >>>>>>>> спасибо за идею, я переделал маленьк
/*
    таки ты заразился на exercism-е лямбдами )
    ок)
*/
========================================================================================================================
6. "    private void addTasksToLocalStorage() {
            String tasksJson = doJsonfromList(this.tasks);

            if (tasksJson.isEmpty()) {
                executeJavaScript("localStorage.removeItem('todos-troopjs')");
            } else {
                executeJavaScript("localStorage.setItem('todos-troopjs', JSON.stringify([" + tasksJson + "]))");
            }
        }
     /*
        вобще - выполнение localStorage.setItem('todos-troopjs', JSON.stringify([]))
        дает нам очистку списка тасок

        так что тут без if-а можно обойтись

        doJsonfromList - немного не выдержан CamelCase (From)
     */"

            >>>>>>>> круто, не знал, спасибо) имя поправил
/*
    ок
*/
========================================================================================================================
7. "    при таком вызове методов пейджа - ок, норм исмпользование should
        все ок
        разницы уже особо нет - shouldBe vs shouldHave

        с проверками - щас подправлю
    */
        @Test
        public void basicTasksFlow() {
            given().completed("1")
                    .atAllFilter()
                    .prepare();

            Tasks.add("2");
            Tasks.shouldBe("1", "2");
            Tasks.edit("2", "edited2");
            Tasks.shouldBe("1", "edited2");

            Tasks.goActive();
            Tasks.shouldBe("edited2");
            Tasks.cancelEdit("edited2", "notedited2");
            Tasks.toggle("edited2");
            Tasks.shouldBeEmpty();

            Tasks.goCompleted();
            Tasks.shouldBe("1", "edited2");
            Tasks.destroy("edited2");
            Tasks.shouldBe("1");
            Tasks.toggle("1");
            Tasks.shouldBeEmpty();

            Tasks.goAll();
            Tasks.shouldBe("1");
        }"

            >>>>>>>> тут только одна проверка добавилась, а я её уже добавил еще с
                    твоих ответов на вопросы)
/*
    ок
*/
========================================================================================================================
8. "    @Test
        public void add() {
            given().atActiveFilter()
                    .prepare();

            Tasks.add("1", "2");
            Tasks.shouldBe("1", "2");
            Tasks.itemsLeftShouldBe(2);
        }
    /*
        Tasks.add("1", "2"); - это 2 действия
        в гивен-действиях - укажи что есть таска "1"

        и в тестируемом действии = добавь таску "2"
        так проверишь создание второй таски в списке - если біла такая цель"

                >>>>>>>> а я чет не подумал что add(1, 2) это по суди два одинаковых add(), и нет смысла проверять
                        добавление нескольких как целостный функционал) сделал как ты сказала с гивеном
/*
    ок
*/
========================================================================================================================
9. "    @Test
        public void clearCompleted() {
            given().active("1")
                    .completed("2")
                    .atActiveFilter()
                    .prepare();

            Tasks.clearCompleted();
            Tasks.itemsLeftShouldBe(1);
            Tasks.goCompleted();
            Tasks.shouldBeEmpty();
        }
    /*
        и после Tasks.clearCompleted(); нужно проверять Tasks.shouldBeEmpty();

        вроде бы, стоит
        перейти на All (c Active  на Completed мы уже переходили)
        и выполнить обе проверки  - Tasks.shouldBeEmpty(); и Tasks.itemsLeftShouldBe(1);
        и в названии метода отразить что мы проверили и clearCompleted и navigateToAll
        и тогда уже метод public void navigateToAllFilter() не нужен
        хотя, конечно - в таком тесте - как выше - мы хуже проверяем фильтеринг ...
        что критично. А раз так - то зачесть это как покрытие тестового действия  navigateToAll - не выйдет

        в общем, раз так - раз мы все равно не сможем проверить фильтеринг тщательно
        то ок
        пусть будет твой вариант, от имени метода, до его реализации
        но все равно - после Tasks.clearCompleted(); тоже нужно проверять Tasks.shouldBeEmpty();
        действие должно быть проверено сразу
        то, что мы потом еще уточнились - то норм
        но и сразу надо все проверить

        таких тестов - есть еще сколько-то
        это учти и для них
    */"

        >>>>>>>> не понял о чем ты, как это проверить после clearCompleted() -> shouldBeEmpty() ?
                это же Active фильтр, он не остается пустой после clearCompleted

                это же как раз тот случай где пришлось делать маленький e2e
/*
    да, про shouldBeEmpty() - ошиблась
    имела в виду - проверку состояния списка тасок
    как буду смотреть код - прокомментирую

    если буду не согласна - просто приведу свой вариант кода
*/
========================================================================================================================
10. "    @Step
         public static void editEnter(String fromTaskName, String toTaskName) {
             edit(fromTaskName, toTaskName);
         }
     /*
         я б не стала реализовывать такой метод
         ограничилась бы edit-ом

         не вижу особых плюсов в существовании editEnter-а
     */"

        >>>>>>>>> ну для очевидности, у нас есть метод editTab, editClickOutside, а editEnter-а нет?
                сразу возникает вопрос, что это за edit такой непонятный, без пояснения)

                как по мне если писать уже такие разные методы, то пусть они будут похожи)
/*
    ну, допустим, ок - нужен editEnter, раз есть editTab, editClickOutside )
    тогда зачем edit, который ты вызываешь внутри editEnter-а? )
*/
========================================================================================================================
11. "    уже писала тебе про это
         не стоит держать в проекте - как ресурс - chromеdriver
         то ты картинки сразу удаляешь, чтоб экономненько было
         то по проектам раскладываешь chromеdriver )

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

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

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

                >>>>>>>> вообще ты права конечно, я подумал подумал и согласился)
/*
    ух ты)
    ок)
*/
========================================================================================================================
12.
==========================================================================================
junitTestClasses
==========================================================================================

        для решения этой задачи - достаточно 2-ух категорий

        buggy - то, что обозначили как buggy
        smoke - то, что обозначили как smoke (можно - за исключением buggy, как вариант)
        all - вообще все
        full acceptance = all - buggy

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

            >>>>>>>> окей, я сделал так, но это не очень KISS как по мне, такое сложное
                    оперирование категориями.

                    собственно, то что full acceptance = smoke исходя их того что ты написала
                    это как последствие такого сложного менеджмента категориями) категорий мало,
                    зато работать с ними труднее, нужно в голове держать лишнюю информацию
/*
    это не так - full acceptance = smoke
    full acceptance = all - buggy
    smoke = smoke OR smoke - buggy

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

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

    на самом деле, в моей схеме
        на примере smoke & buggy категорий - мы увидели вариант - что разметили, то и получили
        на примере all : full acceptance - мы увидели вариант синтетический, не требующий категорий, что тоже иногда полезно будет

    так что для задания - я таки настаиваю на 2-ух категориях)

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

     public class FailSuiteTest {
         @Test
         public void failedTest() {
             System.err.println("SUITE CONFIGURED INCORRECTLY");
             fail();
         }
     }
     /*
        странный сьют)
        я бы даже сказала - что это вообще не сьют

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

                >>>>>>>> ну да, это пустышка для того чтоб просто показать что что то не так
                        пошло во время конфигурации.

                        чем разумнее по умолчанию запускать какой то из съютов?

                        как по мне лучше когда если ты криво наконфигурировал джобу ту же,
                        или вообще забыл указать съют, то удобнее когда все мгновенно падает
                        и указывает ошибку, мол дружище что то ты провтыкал)

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

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

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

    какой профит = не будет вот таких сьютов которые вовсе и не сьюты
    меньше сущностей)
*/
========================================================================================================================
13.
==========================================================================================
mavenProfiles
==========================================================================================
        что то у меня не получилось сделать нормальные профили сделать all и acceptance,
        почему то в них включается DefaultFail тест :\
/*
    это странно, надо смотреть
*/
*****************************************************************************************************************************************************
***************************************************************************************************************************************************
сорсы - https://github.com/AleksanderPopov/automician_course/tree/master/src
****

 public void editConfirmedByEnter() {
 public void editConfirmClickOutside()
/*
    я бы называла тест-методы по одной схеме - если ConfirmedBy - значит у всех так писала бы

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

    одно понятие = один термин
*/
***********************************************************************
    @Test
    public void editConfirmClickOutside() {
        given().active("1")
                .atActiveFilter()
                .prepare();

        Tasks.editClickOuside("1", "edited1");
        Tasks.shouldBe("edited1");
    }
/*
    ты таки не всегда используешь проверку Tasks.itemsLeftShouldBe(...); - даже если это воможно
    а она ведь - уточняет проверки и улучшает покрытие

    и почти не усложняет фиче-тестов

    почему?
*/
*************************************************
public class TasksOperationsAtActiveFilterTest extends BaseTest {
...
    @Test
    public void clearCompleted() {
        given().active("1")
                .completed("2")
                .atActiveFilter()
                .prepare();

        Tasks.clearCompleted();
        Tasks.itemsLeftShouldBe(1);
        Tasks.goCompleted();
        Tasks.shouldBeEmpty();
    }

//привожу свой вариант

    @Test
    public void clearCompleted() {
        given().active("1")
                .completed("2")
                .atActiveFilter()
                .prepare();

        Tasks.clearCompleted();
        Tasks.shouldBe("1");
        Tasks.itemsLeftShouldBe(1);
        Tasks.goCompleted();
        Tasks.shouldBeEmpty();
    }
/*
    после действия clearCompleted - мы и можем, и должны выполнить проверки списка тасок
    они достаточно точно проверяют положение дел после выполнения операции

    поскольку дальшейший переход на Completed - лишь уточняет - что закомпличеных тасок нет -
    то тут уже достаточно  проверки Tasks.shouldBeEmpty()

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

        вот этого -
                Tasks.goCompleted();
                Tasks.shouldBeEmpty();
        уже бы в тест не включала

    тоже - спорить тут уже смысла нет
        похоже, каждый из нас остался при своем мнении
*/
*************************************
 public void deleteByEditToEmpty() {
 public void destroy() {
/*
    в обоих случаях выполняем удаление таски
    а термина - 2 разных - destroy и delete

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

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

    мне ближе идея с термином delete

    тоже - уже не будем спорить
    просто прими мое мнение к сведению
*/
****************************
public class TasksOperationsAtAllFilterTest extends BaseTest {
    @Test
    public void completeAll() {
        given().active("1", "2")
                .completed("3")
                .atAllFilter()
                .prepare();

        Tasks.toggleAll();
        Tasks.itemsLeftShouldBe(0);
        Tasks.goCompleted();
        Tasks.shouldBe("1", "2", "3");
    }
/*
    вот разве что для complete / complete all / reopen / reopen all на All фильтре - еще могу понять -
    что нужно уточниться перейдя на другой фильтр
    на остальных фильтрах/в остальных обстоятельствах мне это кажется совсем лишним

    тут мой вариант такой
*/
    @Test
    public void completeAll() {
        given().active("1", "2")
                .completed("3")
                .atAllFilter()
                .prepare();

        Tasks.toggleAll();
        Tasks.shouldBe("1", "2", "3");
        Tasks.itemsLeftShouldBe(0);
        Tasks.goCompleted();
        Tasks.shouldBe("1", "2", "3");
    }
/*
    после действия тестируемого - проверили все
    и уточнились после перехода на другой фильтр

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

    тоже - уже не будем спорить
    просто прими мое мнение к сведению
*/
***********************************************************************************************************
*************************************************************************************************************
junitTestClasses - https://github.com/AleksanderPopov/automician_course/tree/junitTestClasses

***************
http://joxi.ru/gmvqJvkHLv1Q7r
/*
    не согласна с таким структурным решением
    к предку тест-класса категории не имеют никакого отношения

    потому - я б не держала такое в рамках одной ветки
*/
*********************
public class FailSuiteTest {
/*
    про это - писала выше, в ответах на вопросы
    я б постаралась обойтись без такого класса

    который по сути не сьют
*/
***********************************************************************************************************
*************************************************************************************************************

mavenProfiles - https://github.com/AleksanderPopov/automician_course/tree/mavenProfiles

***

    <build>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
     ...
                <configuration>
                    <groups>${test.includeCategories}</groups>
                    <excludedGroups>${test.excludedCategories}</excludedGroups>
                    ...
                </configuration>
                ...
            </plugin>

        </plugins>
    </build>

    <profiles>

        ...
        <profile>
            <id>full acceptance</id>
            <properties>
                <test.includeCategories></test.includeCategories>
                <test.excludedCategories>
                    com.alexautomician.todomvc.configuration.categories.DefaultFail,
                    com.alexautomician.todomvc.configuration.categories.Buggy
                </test.excludedCategories>
            </properties>
        </profile>

    </profiles>

/*
     ты писал -

      что то у меня не получилось сделать нормальные профили сделать all и acceptance,
            почему то в них включается DefaultFail тест :\

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

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

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

      вот тут - не перечислены groups и excludedGroups - что можно применять к ним синтаксис с запятыми
      http://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html

      тем не менее, по информации от JUnit - вроде как возможно указывать через запятую категории
      https://github.com/junit-team/junit4/wiki/Categories (Using categories with Maven)

      а у Мавена - про перечисление категорий ничего не написано, зато описан интересный момент по использованию наследования категорий)
      http://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html (Using JUnit Categories)

      Лично я применяла только одну указанную категорию или ни одной - в groups и excludedGroups
      так что - точнее не подскажу)
*/
*******************************
/*
    Итого
    по full coverage - считаем задание доделанным. Если посчитаешь нужным - применишь что-то из описанного в этом ревью

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

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