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

    как можно выкрутиться
        использовать тот же http://pastebin.com/

        или в самом проекте с домашками - добавить текстовый файл
        и затем - проект выложить на гит
        и дать линку на нужный файлик в репозитории
*/
at all filter
- create
- edit
- delete
- mark completed //лаконичнее = complete
- uncheck completed //лаконичнее = activate / reopen (выбери термин)
- mark all completed //лаконичнее = complete all
- uncheck all completed should uncheck ALL tasks. Check with precondition = have few completed tasks.
    //лаконичнее = activate all/ reopen all(выбери термин)
    //тут у нас цель - получить максимально сжатый и лаконичный список юз кейсов
    //чтоб потом этот список - помог спроектировать е2е сценарий
- clear completed
- copy/paste
    /*
        это не нужно выносить в список юз кейсов
        мы сосредоточены на проверке функциональности
        именно из этих соображений вноси/не вноси юз кейсы в список

        в прошлой лекции было про это
        примерно с (с 58-й минуты, минут 5-7)
    */
- edit/clear/enter - clears task
/*
    это ты верно подметила)
    там есть еще варианты - все начинается как редактирование
    а далее события развиваются как-то иначе
    ниже это распишу

    это - вынесем в отдельную группу Additional edit operations
*/
- long name (fails btw)
/*
    Это тоже - не будем выносить в данный список
    т к мы будем сосредоточены именно на функциональных проверках
    Почему - опять отсылаю тебя к прошлой лекции (с 58-й минуты, минут 5-7)
*/

/*
    все операции, что нужно - перечислены
    часть пунктов можно написать лаконичнее

    пользуйся для одного понятия - одним термином
    например, если выбрала reopen
    то уже и reopen all используй, а не activate all
    и в других подгруппах - для других фильтьров - тоже применяй уже выбранные термины

    edit/clear/enter - clears task - уйдет в отдельную подгруппу

    и пара пунктов - просто уйдет)
*/
***************************************************************
at active filter
- mark completed. Completed task should disappear in Active. Switch to Completed - it should be there.
/*
    на этом фильтре - вполне будут востребованными
    - create
    - edit
    - delete
    - complete
    - complete all
    - clear completed - и даже это
    если юзер работает так
    зашел - перешел на Active фильтр
    что-то делает комплитит и по финишу все накомпличеное очищает - clear completed
    Он же все помнит - только что это делал
    Так что и clear completed - в эту подгруппу стоит включить

    Про переходы между фильтрами - напишем отдельно
    Про это ниже
*/

at completed filter
- create task. Make sure items left increased but tasks are not shown.
- edit completed. Task should remain completed.
/*
    вряд ли тут create и edit будут востребованными
    из этих соображений - можно не вносить это в список

    а вот delete и reopen и reopen all и clear completed  - таки стоит)
    хотя насчет reopen all - в свете ее не высокого приоритета - еще надо подумать)

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

    нам это нужно - в рамках подготовки к следующему заданию
    в следующем задании - мы будем релизовывать е2е тест-метод который обеспеит smoke coverage
    а в рамках smoke coverage - покрываются лишь высокоприоритетные фичи и лишь единожды
    т е - нужно отличать высокоприоритетное от низкоприоритетного

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


general:
“items left” counting
/*
    это верно, разместить “items left” counting в подгруппе general
    ведь этот счетчик на любом фильтре, после любой операции отражает количество активных тасок

    а вот расписывать - как он меняется - в рамках этого списка точно лишнее
    пункта “items left” counting - достаточно
*/
- mark 1 task completed. Items left should decrease by 1
- delete completed task, check items left has not been changed
- in completed filter have one task completed, create another one. Check items left increased by 1 but task doesn't appear in completed list
- items left is not changed while switching between filters.
- uncheck completed should increase item left by 1.
- deleting task should decrease items left by 1

- navigation through elements (by tab)
/*
    это - если говорить о любом элементе - не есть функциональным юз кейсом
    но  - если говорить например о редактировании таски  -
    то нажатие на tab после ввода нового текста  таски приведет к подтверждению редактирования

    а вот это уже - отдельный юз кейс
    для подгруппы Additional edit operations
    про нее будет ниже
*/
- is not possible to create empty task
/*
    этот пункт предлагаю не вносить
    из тех же соображений - мы сосредоточены на функциональном тестировании
    проверка граничных условий не входит в наши цели
*/

Draft Use Cases
/*
    в данном задании - этого не требовалось

    нужен лишь список с перечисленными действиями/фичами
    планировать сценарий будем позже
*/

- In All filter create 3 tasks. Check all 3 are created in right order with exactly the same text. Items left = amount of all tasks created.
- delete task 1. Check deleting task decreases items left by 1. Task disappears from all filters.
- In All filter mark task2 as completed. Verify Completed filter shows only task 2 and Active filter shows only task 3. Items left decreased by one.
- in Completed filter edit task2 (rename to 23). Check it's still completed. Items left did not changed.
- in All filters mark all completed. Items left should = 0.
- Uncheck All completed. Items left should = amount of all tasks in the app (2)
- in All filter check task 23 as completed and delete task 23. Check it disappears. Items left did not changed (=1)
- in empty Completed filter Mark All Completed. Task 3 should appear, items left = 0.
- in All filter select and copy name of task3, paste in new task, Enter. Active task with the same name should appear. Items left increased by 1.
- focus in the new task field and press Enter. Empty task is not created.
- Clear completed. Completed task disappears from All filter view. Items left is not changed.
******************************************************
/*
 Организуй еще одну отдельную группу - switching between filters
     и распиши для каждого из фильтров
     на какие фильтры можно с данного фильтра перейти

     например
     switching between filters
        from All to
            Active
            Completed
        from Active to
            ...
            ...
        ...

      обрати внимание - с каждого из фильтров можно перейти на 2 других фильтра

      тут термин filter - один из наиболее точных
      фильтруем = согласно некому условию что-то остается видимым, а что-то скрывается
*************************************************************
/*
 еще поэкспериментируй с редактированием таски в списке

        найди еще дополнительные юз кейсы

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

        поэкспериментируй и найди другие варианты развития событий при редактировании
        например, если новое введенное значение = пусто
        или в конце - нажимаем не энтер, а ..., или делаем еще что-то


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


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

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

        пример - если при редактировании текст изменить на пустую строку, то таска удалится
        такой пункт формулируем - delete by emptying text (ты этот пункт обозначила как edit/clear/enter - clears task)

        еще пример, который я выше описала - confirm edit by press Tab
        такой вариант = отличается от стандартного варианта редактирования (когда мы подтвердили редактирование нажатием на Enter)
        и потому мы его выносим отдельным пунктом в этой группе

        есть еще варианты -
        еще один способ подтверждения редактирования(кликнув на какой-то другой элемент)
        и одного способа отмены редактирования
          начали редактировать, внесли новый текст для таски,
          ____что-то-сделали___ (найди - что),
          результат - у таски старый текст - именно потому отмена редактирования
    */
**********************************************
    /*
        Это уже немного на будущее)

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

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

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

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

                    Проверку счетчика Items left - стоит покрыть лишь единожды.
                    В общем-то - это не высокоприоритетная штука.
                    Т к даже если это не будет работать - приложение будет все равно функционально.
                    С другой стороны, на состояние этого счетчика влияет любая выполненная операция.
                    Ввиду этого - в рамках е2е покроем его лишь единожды.
        http://www.tutorialspoint.com/software_testing_dictionary/priority.htm
    */