Smoke E2E flow:

  all (default)
1.  add “1”
2.  edit “1”=>”1a”
3.  complete “1a”
4.  switch from all to active
/*
    отличное начало сценария

    тут - проверка списка тасок будет нужна лишь после 3 шага
    перед переходом на эктив
    и после 3 шага - после перехода на эктив

    первая проверка = проверит = что таски отображаются на all вне зависимости от их статуса
    вторая - допроверит - что таки таску закомплитили
    и проверит фильтеринг - максимально точно - т к состояние списка изменилось

    лучше вместо edit “1”=>”1a”
    использовать edit “1”=>”1 edited”
    тогда далее по коду будет яснее что за таска
*/
*********************************
(active)
5.  add “2”
6.  confirm edit by click outside (“2”=> “2a”)
/*
    из Additional edit operations - только cancel edit
    будет вісокоприоритетной
    и ее стоит тут покрыть
    остальные операции этой группы - покрывать в рамках smoke - расточительно
*/
7.  delete “2a”
/*
    не торопись удалять таски
    пока таска существует - на ней многое можно проверить
    так сєконопис и на добавлении тасок

    если оставлять такой сценарий как сейчас - тут нужна проверка
    т к следующая операция add “3” не проверит предыдущую delete “2a”

    а с учетом выше написанного - на active фильтре
        добавили таску
        отменили ее редактирование
        и выполнили complete all (complete - покрыли выше, этого достаточно)
*/
8.  add “3”
9.  cancel edit by click ESC (“3”=> “3a”)
10. complete “3”
11. switch from Active to Completed
/*
    то же самое - и до и после этого шага - нужны проверки
    рассуждай так
    если следующая операция не проверяет преыдущую - то проверка нужна

    а про неявные проверки - когда они применимы - я ранее тебе писала
*/

(completed)
12. reopen all completed (“1a”, “3”)
/*
    reopen all - тоже приоритет не высокий
    reopen - да, тут как раз самое время покрыть

    а reopen all - в рамках smoke покрытия - не надо покрывать
    когда будет востребована эта операция
    как правило тогда - когда все таски юзер ошибочно закомплитит
    т е - не часто востребована будет
    да и обойтись без нее в работе приложения можно
    этим и объясняется невысокий приоритет reopen all
*/
13. switch from Completed to Active
 /*
    на Active мы уже переходили
    правда, с лругого фильтра

    но - переходили
    т е операцию перехода на Active - мы уже покрыли (правда, на другом контексте
    значит - этого достаточно

    разумнее на Completed фильтре после реопена одной таски - вторую удалить через clear Completed

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

    и в общем-то - сравнительно равномерно распределим покрытое по фильтрам
 */
*************************************
/*
    скорее всего - повторюсь
    но приведу тут важное

    еще - заглядывай в faq
    там тоже к єтому заданию будет что почитать

*/
/*
  Мы реализуем е2е сценарий для smoke покрытия
    это значит - что достаточно покрыть высокоприоритетный юз кейс лишь единожды, на одном из контекстов

    т е - покрыли edit на active - все, этого достаточно
    конечно, с добавлением таски так не получится )
    но - и того количества тасок, что ты создал - не нужно

    но с остальными операциями - это получится вполне

    задача smoke покрытия - быстро дать нам фидбек = все высокоприоритетные операции работают
    не все высокоприоритетные операции работают на всех контекстах
    а именно вот так - что они работоспособны

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

                Примеры высокоприоритетного
                        - добавление задачи - высокоприоритетная штука, потому что если отвалится - приложение не работает
                        - отмена редактирования с помощью esc - во-первых, стандартное поведение, во-вторых - нет альтернативы
                        - закомпличивание/раскомпличивание одной задачи - часто используемое и критично чтоб работало - важный функционал

                Так вот - низкоприоритетные вещи - в smoke-тесте не нужно покрывать.
                Чтобы оставить smoke тест эффективным

                А вот Reopen All - уже имеет приоритет пониже - т к реже будет использоваться, чем тот же reopen
                потому - reopen - стоит покрыть, а Reopen All - уже не стоит

                Проверку счетчика Items left - стоит покрыть лишь единожды. В общем-то - это не высокоприоритетная штука.
                Т к даже если это не будет работать - приложение будет все равно функционально.
                С другой стороны, на состояние этого счетчика влияет любая выполненная операция.
                Ввиду этого - в рамках е2е покроем его лишь единожды.
*/
/*
    про использование неявных проверок через действие
              вариант 1
              add("task1"");
              edit("task1", "task1 edited");
              delete("task1 edited");

              вариант 2
              add("task1", "task2");
              edit("task2", "task2 edited");
              delete("task2 edited");

           Вариант 1 = правильное использование таких проверок через действие

           Вариант2 = не правильное использование
           Т к последующие действия не проверяют состояние ВСЕХ тасок в списке

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

           Также не забывай - после каждого действия должна быть выполнена проверка
           Сразу
           Не получается использовать неявную проверку через следующее действие - используй явную
           Но - действие должно быть обязательно проверено сразу
*/