Comments 3
ИМХО, тест знающий детали реализации и тем более собирающий по ним метаданные — не есть хороший тест.
Хороший тест, тестирующий в том числе транспортный уровень, вообще не должен знать как и вообще на чем написано API
А если вы тестируете только логику, то достаточно тестировать только контроллер. Да и собственно смутно понимаю зачем в WebAPI тестировать транспортный уровень, его уже авторы фреймворка протестировали. Достаточно пары sanity-тестов, чтобы знать что api вообще работает. Имеет смысл тестировать роуты, но так вы их не протестируете.
Хороший тест, тестирующий в том числе транспортный уровень, вообще не должен знать как и вообще на чем написано API
А если вы тестируете только логику, то достаточно тестировать только контроллер. Да и собственно смутно понимаю зачем в WebAPI тестировать транспортный уровень, его уже авторы фреймворка протестировали. Достаточно пары sanity-тестов, чтобы знать что api вообще работает. Имеет смысл тестировать роуты, но так вы их не протестируете.
Моя мотивация была такая:
- Мне нужны были end-to-end. В юнитах мокается ОРМ и нет транспортного уровня. Тесты у разработчиков конечно есть. Я столкнулся с тем, что, чтобы поставить [Required], нужно установить еще и [DataMemeber(IsRequred=true)]. Это тащит за собой [DataContract]. После чего я забыл выставить [DataMember] в некоторых свойствах и они перестали передаваться
- Роуты, как раз, тестируются, потому что я забираю их из метаинформации API
- Я нефигово выигрываю в поддержке, потому что в случае изменении API мои тесты свалятся на этапе компиляции, а не выполнения, мне не нужно вспоминать роуты, я просто пишу код вызова контроллеров, который прозрачно для меня преобразуется в удаленный вызов
1. Юниты тут совсем не причем, раз уж вы тестируете транспортный уровень. Тем более что и транспортный уровень тут ни причем, DataContract — это уровень сериализатора. И тестировать тогда либо тупо на наличие атрибутов, либо то что объект правильно сериализуется.
2. Когда мы итерационно писали одно большое API в условиях нехватки требований, одной из больших проблем было постоянное изменение интерфейсов и соответственно роутов. Соответственно, регулярно ловили баги вызванные опечатками в роутах. В компайл-тайм вы это не протестируете никак, так как код валидный. Тестировать надо снаружи и на соответсвие ВНЕШНЕМУ контракту. А вы контракт генерите на основе тестируемого кода, в котором вполне могут быть баги, благодаря которым сгенерится бажный контракт и вы про это даже не узнаете.
3. Стабильность интерфейса легко достигается обычными юнит-тестами, транспортный уровень WebAPI тестировать незачем, по той простой причине, что там НЕТ вашего кода.
Бизнес-логики в контроллерах вообще быть не должно, тогда она так же элементарно тестируется как изолированно, так и в сочетании со слоем доступа к данным.
4. Ну и говорить про WSDL в контексте RESTFUL API, вообще странно. Есть несколько вариантов аналогичных форматов метаданных для REST, но насколько я знаю ни один из них стандартом не стал.
2. Когда мы итерационно писали одно большое API в условиях нехватки требований, одной из больших проблем было постоянное изменение интерфейсов и соответственно роутов. Соответственно, регулярно ловили баги вызванные опечатками в роутах. В компайл-тайм вы это не протестируете никак, так как код валидный. Тестировать надо снаружи и на соответсвие ВНЕШНЕМУ контракту. А вы контракт генерите на основе тестируемого кода, в котором вполне могут быть баги, благодаря которым сгенерится бажный контракт и вы про это даже не узнаете.
3. Стабильность интерфейса легко достигается обычными юнит-тестами, транспортный уровень WebAPI тестировать незачем, по той простой причине, что там НЕТ вашего кода.
Бизнес-логики в контроллерах вообще быть не должно, тогда она так же элементарно тестируется как изолированно, так и в сочетании со слоем доступа к данным.
4. Ну и говорить про WSDL в контексте RESTFUL API, вообще странно. Есть несколько вариантов аналогичных форматов метаданных для REST, но насколько я знаю ни один из них стандартом не стал.
Sign up to leave a comment.
Как ExpressionTrees помогают тестировать WebApi