про космакс есть интересный пост в сети - кто разрушает российскую кино-науку (это не реклама! ), в целом, на лицо прихватизация канадского хлама, с награждением причастных
да, и при внесении изменений в большой проект, очень сильно обнадеживает, если за каждый юнитом кода следит маленький, узкопрофильный, но зоркий и строгий солдатик :)
не вижу и близко смысла сравнивать тяжелые, долгие и сквозные интеграционные тесты, где на вход даешь A и на выходе проверяешь… G
с быстрыми, легкими и детальными юнит тестами, позволяющими точечно покрыть всю цепочку: A, B, C, D, E, F, G
Как тестирование модуля может зафиксировать ожидаемое поведение системы?
Проблемы проявятся, если сервис будет возвращать json, а не string. Любое добавление поля приведет к тому, что нужно будет переписать каждый подобный тест.
это не проблема, а суть фиксации поведения. Некогда бизнес потребовал string, это реализовали и зафиксировали тестом. Теперь если теперь некий разработчик изменит это поведение — тест упадет, сигнализируя о несовместимости с прежними требованиями.
Если это ошибочно — уф, спасибо тебе, тест!
Если сознательно — меняется тест, фиксируются актуальные требования = ожидаемое поведение системы.
ок. спорный вопрос.
при детальном покрытии быстрыми юнит тестами — долгие и тяжелые интеграционные могут вообще не понадобиться.
юниты дают несравнимо больше профита, и накапливают ценность в перспективе.
спасибо.
я рассматриваю покрытие тестом не как тестирование, а как неотъемлемую часть надежной разработки, написал метод — покрыл, дописал — в тест добавил.
а интеграционные тесты — долгие и тяжелые,
а главное — они сквозные, не способные детально фиксировать функционал.
А в середине те же самые 2+2 с кровавым Enterprise
не совсем, не 2+2, а тогда уж x + 2, легко расширяемый до ax2+bx+c… и далее…
пример элементарный, но принцип очень важный — как покрывать тестами функционал содержащий зависимости и интеграции — применим к любой сложности.
ну традиционно и логично тесты пишутся на методы, это и есть та функциональная единица,
если выделить и обособить вызов зависимости и собственный код, то предельно ясно что мокировать, а что жестко фиксировать в тестах.
Теперь мы готовы загрузить фикстуры в базу данных
$ php app/console doctrine:fixtures:load
в этот момент посыпались ошибки типа SQLSTATE[42601]: Syntax error: 7 ОШИБКА: ошибка синтаксиса примерное положение: "user"
оказало проблема в поле «user», это имя зарезервировано в postgres, пришлось сменить на «uuser» :)
PostgreSQL 9.3
при смене имени. следует учесть это и в шаблонах {# src/Blogger/BlogBundle/Resources/views/Comment/index.html.twig #}
{# ... #}
{{ comment.uuser }} commented {{ comment.created|date('l, F j, Y') }}
PHPExcel жрет память десятками мегабайт даже с настройками кэширования в файл!
Эта библиотека — настоящий кошмар разработчика.
Рекомендую сразу отказаться от нее.
дополню, функцией random_string, которая тут используется
https://gist.github.com/robcowie/e6438369c205c75103ba5e94e09a2f70
про космакс есть интересный пост в сети - кто разрушает российскую кино-науку (это не реклама! ),
в целом, на лицо прихватизация канадского хлама, с награждением причастных
ошибка все-таки была, точнее недочет, и не по бизнесу, а по коду тестов.
проверять xml как строку, согласитесь спорное решение. оно вам отомстило :)
с быстрыми, легкими и детальными юнит тестами, позволяющими точечно покрыть всю цепочку: A, B, C, D, E, F, G
это не проблема, а суть фиксации поведения. Некогда бизнес потребовал string, это реализовали и зафиксировали тестом. Теперь если теперь некий разработчик изменит это поведение — тест упадет, сигнализируя о несовместимости с прежними требованиями.
Если это ошибочно — уф, спасибо тебе, тест!
Если сознательно — меняется тест, фиксируются актуальные требования = ожидаемое поведение системы.
при детальном покрытии быстрыми юнит тестами — долгие и тяжелые интеграционные могут вообще не понадобиться.
юниты дают несравнимо больше профита, и накапливают ценность в перспективе.
я рассматриваю покрытие тестом не как тестирование, а как неотъемлемую часть надежной разработки, написал метод — покрыл, дописал — в тест добавил.
а интеграционные тесты — долгие и тяжелые,
а главное — они сквозные, не способные детально фиксировать функционал.
вы про WebMvcTest? но это уже стандарт гонять тесты контроллера через MockMvc, вы поступаете иначе?
согласен, нужно указать точнее
не совсем, не 2+2, а тогда уж x + 2, легко расширяемый до ax2+bx+c… и далее…
пример элементарный, но принцип очень важный — как покрывать тестами функционал содержащий зависимости и интеграции — применим к любой сложности.
если выделить и обособить вызов зависимости и собственный код, то предельно ясно что мокировать, а что жестко фиксировать в тестах.
не совсем, в статье заложен принцип написания тестов для взаимоинтегрируемых систем
поясните пожалуйста, что вы называете IT-тестами?
в этот момент посыпались ошибки типа
SQLSTATE[42601]: Syntax error: 7 ОШИБКА: ошибка синтаксиса примерное положение: "user"оказало проблема в поле «user», это имя зарезервировано в postgres, пришлось сменить на «uuser» :)
PostgreSQL 9.3
при смене имени. следует учесть это и в шаблонах
{# src/Blogger/BlogBundle/Resources/views/Comment/index.html.twig #}
{# ... #}
{{ comment.uuser }} commented {{ comment.created|date('l, F j, Y') }}
не настолько функциональная, но именно при генерации больших файлов — работает отлично.
так и пишут сами:
Эта библиотека — настоящий кошмар разработчика.
Рекомендую сразу отказаться от нее.