PHPUnit и тестирование заголовков

[whirlwind]

Вот очень опасные слова твои для неопытного в этих делах человека. Легко сделать неправильный вывод.

Насчет "не слушай", согласен, погорячился. Насчет того, что тестирование заголовков это не кейс - не согласен. Во-первых, зависит как сделано. Если разные заголовки это результат работы написанного нами кода, то он должен быть протестирован. Любая ветка развития событий должна быть протестирована. Модульный тест и хороший ОО-дизайн просто позволяет снизить математическую сложность тестируемого куска, следовательно и теста. Во-вторых, граница между функциональным и модульным довольно зыбка. По этому стараюсь не цепляться и всем советую.

Что касается как бы я решал эту проблему, на первый взгляд здесь классический случай request/response. Контроллер формирует response, который тестируется на заголовки и все остальное, что душе угодно. Дальше можно очень тонкую прослойку сделать типа драйвер вывода, который весь респонз будет флюшить. И тогда на этот драйвер будет 1 функциональный тест, который будет завязан на энвайрмент, а не на кажный контроллер, что действительно не хорошо. Но это лучше, чем много тестов контроллеров, каждый из которых завязан на энвайрмент. Но это не для всех случаев подходит, например для больших объемов данных не подойдет. На границах I/O всегда возникают какие то проблемы с тестами и нужно рассматривать конкретный случай индивидуально. Общий подход - снизить количество таких пограничных случаев за счет правильного дизайна. Тесты нужно уметь слушать. Если они говорят: нечто делать слишком тяжело или вам лень делать на это тест, стоит внимательно присмотреться локально к дизайну - как это делается. Вероятно выбрано не лучшее решение.

 

[hell0w0rd]

Реально, чего тут до сих пор обсуждается? Сделал мок Response и вперед.

 

[флоппик]

Что касается как бы я решал эту проблему, на первый взгляд здесь классический случай request/response. Контроллер формирует response, который тестируется на заголовки и все остальное, что душе угодно. Дальше можно очень тонкую прослойку сделать типа драйвер вывода, который весь респонз будет флюшить.

Реально, чего тут до сих пор обсуждается? Сделал мок Response и вперед.

Господа, вы не читали ТС, да?

Но, отдаст ли вызов этого кода 404 или например, сгенерирует ошибку (header already sent) или скажем, этот заголовок перекроет другой заголовок в другом участке кода. Вот и надо получить заголовки в буфере.
Поэтому, я тестируя контроллер хочу удостовериться в правильности заголовков.

 

[Активист]

Господа, вы не читали ТС, да?

И? Я протестировал, отдает leyout посредством вызова контроллера через диспетчер верные заголовки и код ответа, если вы считаете, что тестировать это не нужно, то Бог вам в помощь. Я протестировал вывод layout (он у меня отвечает за макеты ответа) как в html режиме, так в и режиме gateway (json) (два потомка от Layout). Устроили филосовский спор, млять. Моя задача протестировать код что бы работал как часы в т.е. числи и заголовки ответа. Ибо "слышал", что нужно передавать данные о передвижении людей между регионами в фсб мин транс и распиздяйство ссылать на ошибки кода ни как не получится.

 

[fixxxer]

Это все хорошо, только не имеет отношения к юнит-тестированию. Мне кажется, тебе нужен BDD.

 

[WMix]

Активист, может просто глянуть как это делают другие
https://github.com/zendframework/zf2/blob/master/tests/ZendTest/View/Helper/LayoutTest.php
https://github.com/zendframework/zf2/blob/master/library/Zend/Test/PHPUnit/Controller/AbstractHttpControllerTestCase.php

 

[Absinthe]

ZF2 - не лучшее место, куда стоит смотреть в поисках советов.

 

[Активист]

Бл..ть,, я вот одно не понимаю, что вам не поравилось конкретно - то, что я протестировал код ожидаемого ответа или установку заглолка ContentType ?

 

[Absinthe]

Бл..ть,, я вот одно не понимаю, что вам не поравилось конкретно - то, что я протестировал код ожидаемого ответа или установку заглолка ContentType ?

Мне не понятно, почему для такой задачи ты не используешь BDD-инструменты вроде Codeception.

 

[hell0w0rd]

Господа, вы не читали ТС, да?

Еще как читал. Это нужно протестировать для Request-объекта и забыть о подобных тестах. А как его тестировать - туча способов.

 

[grigori]

Активист, действительно, глянь http://codeception.com/docs/10-WebServices

а кто знает как на приемочных тестах проверять race condition? в биллинге это одна из самых серьезных проблем

 

[fixxxer]

для начала надо его воспроизвести (реплеем логов, например), но тайминги соблюдать сложно

ну еще можно понаставить sleep(random) в подозрительные места и устроить fuzz testing

 

[whirlwind]

race condition это не функциональная проблема -> не тема для приемочного тестирования.

sleep для тестирования multithreading issues нельзя использовать. Любые системные вызовы, которые меняют очередность треда в шедулере, нельзя использовать. Потом их убираешь и проблема возвращается.

 

[fixxxer]

ну а что делать если реплеем не воспроизводится? с рандомными слипами и фаззом (с тем же srand) есть хотя бы шансы нарваться и воспроизвести

 

[whirlwind]

Блокирующим вызовом ты рисуешь границу кванта, указываешь шедулеру, где отпустить поток. Шанс, что проблема вообще исчезнет, гораздо выше, чем шанс нарваться на проблему. Эти проблемы действительно одни из самых сложных в локализации.

 

[fixxxer]

Я это все понимаю, потому и fuzz. Как вариант можно грузить cpu хренью n итераций вместо слипа. Какие еще варианты-то?

 

[whirlwind]

Ну вариантов решения проблемы не так много. Повысить атомарность или изолированность (critical section, serialized). Либо найти кейс, путем постепенного сужения области поиска. Здесь зависит от используемых инструментов. В общем тема довольно обширная. Лучше отдельно и в контексте конкретной проблемы разбирать. Тут точно оффтоп.

 

[флоппик]

Еще как читал. Это нужно протестировать для Request-объекта и забыть о подобных тестах. А как его тестировать - туча способов.

Так он не хочет иметь единую точку ответственности. Он хочет понатыкать header-ов в коде и ловить ошибки тестами.
А потом у него будут тесты проходить, потому что на локалке у него насильно апач отдает text/html например, на любой контент. А на сервере будет нджинкс, но "тесты же проходили!".

У него реально проблемы глубоко в фундаменте, сколько раз пытались объяснить, что он не пишет ООП, а лапшу в объектном синтаксисе.

 

[Активист]

Так он не хочет иметь единую точку ответственности. Он хочет понатыкать header-ов в коде и ловить ошибки тестами.
А потом у него будут тесты проходить, потому что на локалке у него насильно апач отдает text/html например, на любой контент. А на сервере будет нджинкс, но "тесты же проходили!".

У него реально проблемы глубоко в фундаменте, сколько раз пытались объяснить, что он не пишет ООП, а лапшу в объектном синтаксисе.

Ты за меня не додумывай, а? А еще не стоит говорить о человеке в третьем лице при его присутствии. И если что-то хочешь спросить - спроси, ок? И код ты давно не видел и код. "Понатыкать header-ов в коде", нет, хейадеры слать будет только унаследованные Layout. Но, еще есть закрытое скачивание контента - Layout_Attachment, есть и Layout_Json, и вывод печатных форм через SVG / PDF (Layout_Svg) и экспорт XLSX (Layout_Xlsx). И везде нужна проверка заголовков и проверка установки верной кодировки, я так тестирую Layout, а не проверяю аттрибут, потому тестировать мне нужно резальтат выполнения кода - результат - это заголовок, посланный Layout, а не значение аттрибута.

 

[флоппик]

Лол.