/*
    Остались финальные штрихи)
    Практически все ок)
*/
    public void testTaskLifeCycle() {
        Configuration.timeout = 20000;
        /*
            если таки эта настройка в сочерании с плохим инетом - дает хороший результат
            то используй ее

            кратко - что это за настройка
            она по умоляанию = 4 секундам
            и это тот период времени, который selenide віолняет ждущие проверки

            например - для такого кода ....shouldBe(...)
            вот этот кондишен - в рамках интервала времени = Configuration.timeout
            будут выполняться последовательные проверки условия этого кондишена
            если условие выполнено - все ок, мы все проверили, идем дальше
            если условие не выполнено - будем снова проверять условие - и так пока Configuration.timeout не истечет
            если этот интервал истек, и за него кондишен так и не выполнился - тест падает

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

            соотвественно - если у тебя медленный инет
            или если у тебя медленное приложение - надо регулировать Configuration.timeout

            настройки, которые влияют на выполнение тестов - лучше делать в рамках тест-класса - до запуска всех тест-методов
            (их может быть и несколько)
            для этого можно реализовать @BeforeClass-метод или static initialization block
            http://junit.sourceforge.net/javadoc/org/junit/BeforeClass.html
            http://www.javamadesoeasy.com/2015/06/differences-between-instance.html

            реализуй это одним из выше предложенных способов
        */

        ...
        filterCompleted();
        ...
        cancelEdit("2", "777");
        /*
            все же на этом фильтре не так часто редактируют таски, как на all или active
            тут то уже задачи - выполненные (закомпличеные)
            потому - все же логичнее это покрыть на эктиве

            настаивать не буду - т к и тут есть смысл это делать
            в том числе и исходя из соображений более равномерного распределения операций по фильтрам
        */
        assertVisibleTasksAre("1 edited", "2");
        //reopen
        toggle("2");
        /*
            где проверка?
        */
        clearCompleted();
***********************************************************
    private SelenideElement startEdit(String oldTaskText, String newTaskText) {
    /*
        в слеке писала - как обойтись без переменной SelenideElement element
        если код можно написать лаконичнее - без потери точности и наглядности - надо это делать)
    */
*************************************