public class TodoMvcPage {

    private ElementsCollection tasks = $$("#todo-list>li");
    private SelenideElement newTaskInput =  $("#new-todo");

/*
    я бы не стала скрывать эти переменные как private
    возможно - кому-то в тест-методе понадобится с ними поработать
    так почему нет?

    советую объявить как public

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

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

*/
*******************************
public void givenAtAll(GivenHelpers.Task... tasks) {
public void givenAtActive(GivenHelpers.Task... tasks) {
public void givenAtCompleted(GivenHelpers.Task... tasks) {
/*
    я бы и гивен-методы аннотировала как Step

    а вот насчет того - надо ли так аннотировать проверки...
    вопрос неоднозначный

    если важно в отчете их видеть - да, нужно аннтоировать
    а если в отчете не хочется отвлекаться на проверки - тогда не надо)

    зависит от потребностей / целей
*/
***************************************

    @Step
    public void cancelEdit(String oldTaskText, String newTaskText) {
        setNewTaskText(oldTaskText, newTaskText).pressEscape();
    }
/*
    не по теме этого ревью
    но раз уж за @Step заговорили

    если бы в тест-методе использовалась строчка setNewTaskText(oldTaskText, newTaskText).pressEscape();
    и сам метод setNewTaskText был аннотирован @Step
    то в отчете бы отразилось setNewTaskText(oldTaskText, newTaskText)
    а вот то, что после точки - нет

    потому - хороший выход - делать как ты
    реализовать специальный метод и его использовать
*/
*******************************
private SelenideElement setNewTaskText(String oldTaskText, String newTaskText) {
/*
    из описанных выше соображений - не стала бы делать метод private

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

    но это нас спасает то, что мы вызываем методы пейджа как
    указывай пейдж.метод(...)

    всегда четко ясно - где какой метод (есть же одноименные)
    интересно, как в следующей работе это решишь)
*/
************************************
/*
    это пока просто к сведению
    потом - когда будем делать работы в отдельных репозиториях - потренируешься
    пока оставь текущую структуру проекта
*/
/*
    http://joxi.ru/nAyqEx7HXvxQoA

    вот пример хорошей структуры проекта

    в src \ main

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


    в src \ test

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


    про пекеджи еще немного)
    если GroupID = com.somesite
    а проект todomvctest
    то пакет корневой должен быть com.somesite.todomvctest

    логика  - чтобы "не смешивались имена сущностей"

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