@app.route('/todo/api/v1.0/tasks/reset', methods = ['GET'])
@auth.login_required
def reset_tasks():
    global tasks
    tasks = [
        {
            'id': 1,
            'title': u'Buy groceries',
            'description': u'Milk, Cheese, Pizza, Fruit, Tylenol',
            'done': False
        },
        {
            'id': 2,
            'title': u'Learn Python',
            'description': u'Need to find a good Python tutorial on the web',
            'done': False
        }
    ]
    return jsonify( { 'tasks': map(make_public_task, tasks) } )

/*
    смотри, весь этот кусок - точная копия объявления tasks при старте

    ты при старте
        объяви не tasks, a default_tasks
        и следом присвой переменной tasks - копию default_tasks

    и в этом методе - делай такое же присваивание = заново заполни tasks
    и затем верни get_tasks()

    посмотри на линки и комментарии в прошлом ревью
    может, конечно, ты просто забыла обновить этот файлик в проекте)

    я в прошлом ревью не только про это писала
    насчет rest-server.py
    строки 3-38 прошлого ревью

*/
*****************************
public static String uri = baseUri + "/todo/api/v1.0/tasks";

/*
    все ок с реализацией Configuration.baseUri
    конечно, стоит использовать
    Configuration.baseUri
    а не  baseUri

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

    @Before
    public void testReset() {
        TasksApi.reset();
        TasksApi.assertTasks(DEFAULT_TASKS[0], DEFAULT_TASKS[1]);
        /*
            если вынести вспомогательное предварительное действие
            в @Before-метод - это в общем ОК
            (плюсы и минусы этого решения - рассмотрели в прошлом ревью строки 403-415)

            то добавлять еще и assertTasks - точно перебор

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

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

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

            а если мы тут используем assertTasks
            то получается - что еще на уровне предварительных действий
            используем и тестируемое действие - get()
            мы тут запросто обойдемся без assertTasks
            это только улучшит наш код)

            еще важно
            это - не тест-метод
            это - бифор-метод - для создания тестовой ситуации
            имя метода - не должно начинаться с test

            можно и єтот метод назвать reset()
            и будет ОК

        */
    }
*********************************************************
    @Test
    public void testReadAll() {
        //TasksApi.reset();
        /*
            в бифоре - вызвали ресет + гет
        */
        List<Task> actualTasks = TasksApi.get();
        /*
            и теперь проверяем гет)
        */
        assertEquals(Arrays.asList(DEFAULT_TASKS), actualTasks);
    }
/*
    поправишь реализацию бифор-метода - и тут логика будет стройнее
        в бифоре - сделали ресет = предварительные действия
        в тест-методе - гет = тестируемое действие
        и проверили результат

    все хорошо и красиво
*/
***************************************
@Test
    public void testUnauthorizedRead() {
        Response response = RestHelpers.requestTo(uri).get();
/*
    тут без ущерба для кода - можно заимпортить RestHelpers.requestTo
    и использовать просто requestTo

    конечно - это субъективно)

        я придерживаюсь такого принципа

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

        иначе - использую import static

        так - например -
        в селениде проектах - использовав кондишенов empty / visible -
        мы использовали import static и не уточнялись
        до имени класса - т к и так все понятно из контекста

        а вот By.name(...), String.join(... - я бы уточнялась до класса -
        т к по одному имени метода непонятно - что за зверь
        и тот кто код читает - будет вынужден посмотреть - что мы там наимпортили

        не настаиваю в данном случае
        но ход мыслей вот такой)
*/
******************************************
    @Test
    public void testRead() {
        Task task = authorizedRequestTo(uri + "/2").get().readEntity(TaskContainer.class).getTask();
        /*
            вот для этого - можно было бы в TasksApi реализовать Task get(int taskId)
            заодно и код ответа в методе проверишь)
        */
*************************************************************
public void testCreateTaskWithFullInformation() {
/*
    тут мы уточнялись до WithFullInformation - т к у нас было 2 варианта
*/
****************************************
public void testUpdateFullInformation() {
/*
    а тут - у нас один вариант
    потому можно и не конкретизироваться до FullInformation
*/
**************************************
    public void testUpdateFullInformation() {
    public void testDelete() {
/*
    в обоих методах - используешь таску с ид=2

    разнообразь тесты)

    в одном методе - с первой поработай
    во втором - со второй

    пойдет на пользу покрытию
*/
***********************************
public void testCreateUpdateDelete() {
/*
    очень правильно - что тут поработала во всех шагах - с добавленной таской
    т к в предыдущих тестах мы редактировали и удаляли дефолтную таску


    тоже разнообразили тестовые ситуации
    и улучшили покрытие
*/
*****************************************
    public static List<Task> get() {
        return authorizedRequestTo(uri).get().readEntity(TasksContainer.class).getTasks();
    }
/*
    И тут - аналогично другим методам
    можно было бы и код ответа проверить

    но - наверное не стоит)
    спорный такой момент

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

    хотя - если это важно - про код ответа
    то надо бы тут проверить

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

    тут - что проверять - надо по месту сориентироваться
    чтоб и лишнего не делать
    и важного не упустить

    от многого зависит
    в том числе и от наличия юнит-тестов

    Яков писал об этом в слеке (в чате на нас троих)
    если не видела - маякни

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

    не забудь про код на питоне - приложи свежую версию)
*/