По твоему новому решению
https://github.com/AleksanderPopov/automician_course/tree/master/src

Я бегло тебе ответила
http://joxi.ru/BA0p30gsJJbq7A (edited)
1 - начни  тут фразу с page .
будет нагляднее

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

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

есть немного ответов в faq
https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#heading=h.c6yq8ne03bpo

может пригодиться вот это
http://joxi.ru/l2ZNaR0F83gJv2
Посмотри видео Якова про это - https://drive.google.com/file/d/0B8hgIBw8-V-AdGxxU1R3enl1RzQ/view?ts=567ab8d7

далее - вот эти 2 материала - изучи и учти все по максимуму
https://drive.google.com/file/d/0B8hgIBw8-V-AdGxxU1R3enl1RzQ/view
https://docs.google.com/document/d/1a9SKszjXXUBWeX2a2CfPbZHbOuTf7Sn4zQ4-qyMOa8k/edit?usp=sharing

В итоге - получишь окончательную версию этого дазания  - по Smoke E2E сценарию
вот это - отдавай на ревью

*************************************************************
Дальше

посмотри вот это
https://docs.google.com/document/d/1Q5VGnE5dCxvAAUJA6ADsBH7_Tr90vXpzqQYMGma1iRw/edit?usp=sharing
одно видео  - ты уже видел
второе - возможно что нет

после этого - работаем с тест-планом

уже есть табличка и она ок

    теперь - планируем реализовать Smoke покрытие - с помощью одного е2е сценария и нескольких (2-3) фиче-тестов
    смысл Smoke покрытия - не меняется
    покрываем только высокоприоритетное, только единожды, равномерно распределяя покрытие по фильтрам

    придется чуть упростить текущий е2е - чтоб часть высокоприоритетных операций покрыть в фиче-тестах (или атомарных тестах)


    У нас такой е2е - что уже все высокоприоритетное покрыто
    Мы - без особых переделок е2е - можем спокойно убрать из него edit & cancel edit & delete
    И покрыть это (все 3 операции, или лишь какие-то 2 - на твое усмотрение) в фиче-тестах

    Что из себя будет представлять фиче-тест

        подготовительные действия (не считаем как покрытие)
        тестируемое действие
        проверка (или проверки)

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

        Потому - разумно в фиче-тестах
        в качестве второй проверки после тестируемого действия - покрывать и проверку items left

        Это практически не усложнит фиче-тест, но улучшит покрытие

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

        Когда будешь планировать фиче-тесты - учитывай равномерное распределение покрытых операций по фильтрам

первая цель - получить новую картинку - smoke покрітие реализованное с помощью одного е2е сценария и нескольких (2-3) фиче-тестов
     это сделай, потом на ревью отдашь вместе со всем остальным

*******************************************************************
вторая цель - написать эти распланированные тесты  (упрощенный уже е2е сценарий и 2-3 фиче-теста)

смотри https://drive.google.com/file/d/0B8hgIBw8-V-Ab0liQ2dCQnlPNVE/view
    реализуй тесты - этот тест-класс - тоже отдашь на ревью

вот сразу тебе - что стоит учесть - при разработке фиче-тестов

     имя фиче-теста - что тестим и на каком фильтре

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

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

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

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

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

    Это к общему сведению)

        Есть разные способы выполнять предварительные действия
        Мы сейчас делаем это через действия на UI (User Interface)
        А есть еще методы - работать непосредственно с данными (далее вы такое тоже попробуете)
        Так вот через действия на UI - предварительные действия не быстрые и часто не достаточно надежные
        А через непосредственную работу с данными - предварительные действия быстрые и надежные

        Если предварительные действия медленные или не надежные
        То проверка в конце предварительных действий нужна

        А если мы уверены - что после предварительных действий гарантировано все ОК,
        то и проверок не надо после предварительных действий

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

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

*******************************************
Итого - отдашь на ревью
    тест-метод Smoke
    тест-план с новым Smoke покрытием (упрощенный уже е2е сценарий и 2-3 фиче-теста)
    тест-класс - реализующий все это согласно тест-плана

    смысла останавливаться - нет
    делай все это
    материал - для тебя вполне посильный