sources (new task 10 + new task 11 + last review changes) - https://github.com/AleksanderPopov/automician_course/tree/master/src/
   разбор full coverage

*********************************************
public class AllurePublisher extends TestWatcher {
...
    @Attachment(value = "Page-screenshot", type = "image/png")
    private static byte[] publishScreenshot(String path) {
        ...
    }

    @Attachment(value = "Page-source", type = "text/html")
    private static byte[] publishHtml(String path) {
        ...
    }

 ....
    public static class ImmediateAction {

       .....

        private static void publish(boolean saveScreens, boolean saveHtml) {
            String path = getPathOf(screenshot());
            if (saveScreens) {
                publishScreenshot(path);
                delete(path, ".png");
            }
            if (saveHtml) {
                publishHtml(path);
                delete(path, ".html");
            }
        }

    }
/*
    писала тебе и в ответах на вопросы
    что решение со скриншотами - стало хуже

    и сейчас это же пишу

    вот так, в иннер-классе - юзать функционал оутер класса
    ну, нет

    не понятно, что какой класс должен делать и за что отвечать

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

    при том, что в прошлом решении - было дублирование
    оно все равно было лучше этого

    по моему мнению)
*/
****************************************************
    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....
            которые будут вызывать конструктор с нужным параметром

    не настаиваю на изменениях
    твой вариант - не канонический)
*/
*****************************************************************
        private Builder tasks(TaskType taskType, String... taskNames) {
            Stream.of(taskNames).forEach((taskName) -> tasks.add(new Task(taskType, taskName)));
            return this;
        }
/*
    набрался)
    на экзерцизме скорей всего)

    ок вариант
*/
**************************************************
    private String doJsonfromList(List<Task> tasks) {
        if (tasks.isEmpty()) return "";

        StringBuilder result = new StringBuilder("");

        for (Iterator<Task> iter = tasks.iterator(); iter.hasNext(); ) {
            Task task = iter.next();
            result.append("{")
                    .append("'completed':").append(task.type.lsValue)
                    .append(",'title':'").append(task.name)
                    .append("'}")
                    .append(iter.hasNext() ? "," : "");
        }
        return result.toString();
    }
/*
    вариант рабочий
    но код можно упростить

    также - даже если фигурные скобки в if / for / ... блоке синтаксически не требуются - применяй их
    согласно conventions это нужно
    https://google.github.io/styleguide/javaguide.html#s4.1.1-braces-always-used

    см упрощения
*/
    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

    твой вариант тоже ок)
*/
*****************************************
    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)
 */
***********************************************
public class TasksIntegrationFlowTest extends BaseTest {

    @Test
    public void basicTasksFlow() {
        given().completed("1")
                .atAllFilter()
                .prepare();

        Tasks.add("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");
    }
}
/*
    при таком вызове методов пейджа - ок, норм исмпользование 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");
    }
***********************
    @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"
    так проверишь создание второй таски в списке - если біла такая цель


*/
*********************************
    @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();
    действие должно быть проверено сразу
    то, что мы потом еще уточнились - то норм
    но и сразу надо все проверить

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

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