package ua.net.itlabs.hw1;
...
public class TodoMVCSmokeAndFeatureTest {
/*
    Информация в имени тест-класса - SmokeAndFeature - не помогает

    Smoke - это важно
    но информацию о покрытии - лучше отражать по-другому. Дальше на курсе будет и это)
    Smoke покрытие может быть реализовано и набором нескольких тест-методов - из разных тест-классов
    В общем  случае - это не характеристика тест-класса
    а характеристика набора тест-методов

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

    получаем - что наще уточненное имя тест-класса - TodoMVCSmokeAndFeatureTest
    реально мало что поясняет
    посмотри на раздел по неймингу - faq

    TodoMVCTest - и тут такое имя подойдет
    а вот разместить такой тест-метод - стоит в другом пекедже
    не в ua.net.itlabs.hw1
    а в ua.net.itlabs.придумай имя пекеджа

    Уже это обсуждали - структурную информацию - отражай через структуру пекеджей

    в Java - в рамках одного проекта, в разных пекеджах, могут быть классы с одним именем
    так что - это не проблема
*/
****************************
    @Test
    public void testTasksLifeCycle() {

        ...

        filterAll();
        toggleAll();
/*
    откуда взялся повторный complete all ?
    В окончательнос решении - http://pastebin.com/L5ANvSqE
    этого не было

    тут - была цель упрощать е2е
    а и мы не планировали такого -
    https://docs.google.com/spreadsheets/d/18tnNJA1B-wm023AhNZ8nJRNS1ENy__bAicQyycWse-c/edit#gid=448037844

    убери усложнения

    и попробуй применить тексты тасок не  task1, task2 ...
    a - a,b,c ....
    Это Яков на видео показывал - такой способ сделать код легче для восприятия
    это касается всех тест-методов
*/
***********************************
    @Test
    public void testEditTask() {

        add("task1");
        edit("task1", "task1 edited");
        assertItemsLeft(1);
        assertTasks("task1 edited");

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

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

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

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

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

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

    в итоге - с учетом этих рекомендаций - получим
*/
    @Test
    public void testEditTaskAtAllFilter() {
        //given
        add("a");

        edit("a", "a edited");
        assertTasks("a edited");
        assertItemsLeft(1);
    }
/*
    Примени те же подходы и к другим атомарным тест-методам
*/
**********************************

    @Test
    public void testDeleteTask() {
/*
    а если бы в предварительных действиях - добавил 2 таски - то смог бы и assertItemsLeft проверить
    и более интересную тестовую ситуацию покрыть - удаление второй таски в списке
*/
**************************************