src/main/java/com/todomvc/page/TaskManagerPage.java

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

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

    когда есть несколько пейджей - тогда, конечно, имя пейджа должно быть точнее

    твой вариант имени класса пейджа - тоже ок
*/
************************************
private ElementsCollection tasksSheet = $$(".view");

/*
    мы оперируем коллекцией
    что это за элементЫ = это таскИ
    это не одна страница тасок, а именно коллекция тасок

    потому - тут уместнее имя tasks

    что касается селектора - можно его подобрать нагляднее и точнее

    http://joxi.ru/Q2KpJYOs9jW17A
    внутри элемента с id = todo-list
    есть элементы li
    собственно - именно эти элементы li - и есть таски

    элементы с классом view - это уже подчиненные элементы тасок
    пока мы реализовываем удаление или закомпличивание таски - все ок -
    нам достаточно коллекции $$(".view")

    а как дело дойдет до редактирования таски - нам понадобится именно коллекция элементов li

    строй селектор, оттолкнувшись от элемента с id = todo-list
    именно это даст наглядность и бОльшую точность

    если просто получать элементы $$("li") или $$(".view") - слишком велика вероятность, что
    в приложении будут еще элементы, помимо тасок, которым такой локатор подойдет


*/
*********************************
    public void create(List<String> taskNames) {

        for (String name : taskNames) {
            $("#new-todo").setValue(name).pressEnter();
        }
    }
/*
    будет удобнее работать с методом, у которого параметр  String ... taskNames

    это никак не повлияет на реализацию метода
    но - упростит его вызов

    http://www.linkex.ru/java/varargs.php
*/
*****************************************
    public void switchTask(String taskName) {

        tasksSheet.findBy(text(taskName)).find(".toggle").click();
    }
/*
    посмотри перевод слова toggle
    раз у нас на уровне реализации самого приложения - есть подходящее слово toggle
    так его разумнее и использовать в качестве термина
    toggle = переключить

    в других методах - в имени метода ты не уточнялся до Task
    и тут тоже стоит не уточняться - чтоб единообразно было
    toggle(String taskName)

    по реализации - практически все ок

    единственный момент
    есть кондишен text - тут проверяется условие - в текст элемента входит  такой-то текст
    а есть кондишен exactText - тут уже проверяется - текст элемента равен такому-то тексту

    использовав exactText - получишь более точный результат
*/
******************************
    public void switchAll() {

        for (SelenideElement label : tasksSheet) {
            label.$(".toggle").click();
        }
    }
/*
    по имени метода - то же самое - термин toggleAll - будет уместнее

    по реализации - речь шла об использовании вот єтого чекбокса http://joxi.ru/12MDGYXu4jLN3m

    в прошлом ревью писала про это) - строки 212-213
*/
************************************
public class TodoMVCTest {

    private TaskManagerPage page = new TaskManagerPage();

    private List<String> listOfTasks = Arrays.asList("task1", "task2", "task3", "task4");
    /*
        какие тестовые данные стоит выносить в переменные, а какие - не стоит - важный вопрос)
        и тут надо быть осторожным - лишних усложнений без причин не стоит делать)
        В данном случае - нам точно переменные для тестовых данных - ни к чему
        далее на курсе - будут примеры, когда мы будем для тестовых данных использовать переменные.
        Но - это скорее исключения из общего правила )

        Приведу коммент Якова для другого студента - на эту же тему -
        почему не нужно тестовые данные выносить в переменную

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

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

              поэтому в селениум тестах стоит проверять только высокоприоритетные функциональные вещи
              (а остальное - выгодней проверять в юнит тестах, вспомни пирамиду тестирования)
              http://martinfowler.com/bliki/TestPyramid.html

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

          а значит - мы можем упростить тексты даже до чего-то типа "1", "2", "3", ... или "a", "b", "c"

          и также  - мы не должны скрывать эти тестовые данные, которые являются частью тестовой логики
          а значит - помещать их в переменные - не стоит
          это два :)

        и даже если эти тексты поменяются, например мы решили поменять "1", "2", "3" на "a", "b", "c"
        по какой то причине
        то find&replace никто не отменял ).
        В этом случае, когда у нас тестовые данные подвязаны к тестовой логике тестов в одном классе -
        это совсем не проблема.
        это три.

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

        Посмотри доклады Андрея Солнцева. Зацени, как он вообще динамит этот DRY в тестах.
        А они в своем codeborne, выпускают банковские продукты совсем без тестировщиков ;)

        Это что-то да значит. Да и много других докладов есть на эту тему.
        Кажется вот в этом докладе еще об этом идет речь: https://www.youtube.com/watch?v=uU2bJPK6Irw

        Так что рекомендую выкинуть переменные нафиг :)

    */

    @Test
    public void testTodoMvc() {
    /*
        имя тест-метода - ничего не уточнило)

        про TodoMvc - в имени тест-класса уже написали
        тут - повторяться не нужно

        посмотри вот эти советы
        https://docs.google.com/document/d/10qSwWTQ6pGfVZSwOes-1QSmdflMiGD2U_y53VHq2m20/edit#bookmark=id.txqig9rkgybo

    */
        open("https://todomvc4tasj.herokuapp.com/");
        /*
            используй пропуски строк - как средство форматирования кода
            отделяй блоки кода друг от друга
            вот тут бы я пропустила строку
        */
        page.create(listOfTasks);
        /*
            с учетом выше написанного про тестовые данные
            и про изменение типа параметра метода create - тут будет код попроще

            page.create("task1", "task2", "task3", "task4");

            писала про проверки - строки 352-356

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

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

            тут - нужна проверка

            и далее по коду - все действия должны быть проверены
            еще посмотри на текст в строках 397-407 прошлого ревью - учти эти моменты
        */
        page.delete("task2");
        page.switchTask("task4");
        page.clearCompleted();
        page.switchAll();
        page.clearCompleted();
    }
}