Пользователи Pex: каковы ваши впечатления от Pex и автоматизированного исследовательского тестирования в целом?

Я думаю, что Pex как инструмент исследовательского тестирования действительно интригует. В этом отношении я считаю, что это то, что я хотел бы передать QA для использования.

Как инструмент TDD, он требует некоторой доработки, поскольку TDD - это проектная деятельность. Однако мне нравится направление, в котором движется Пели. Есть что сказать об автоматизированном вспомогательном дизайне. Например, только потому, что TDD - это инструмент дизайна, у меня нет причин, по которым у меня не может быть автоматизированного инструмента, указывающего на потенциальные крайние случаи, пока я проектирую, верно? Качество сборки с самого начала.

Посмотрите этот пост, в котором Пели использует Pex в рабочем процессе в стиле TDD. http://blog.dotnetwiki.org/TDDingABinaryHeapWithPexPart1.aspx

Pex позволяет вам писать модульные тесты параметризованный. В этом смысле он полностью вписывается в поток TDD / модульного тестирования: напишите тест, попросите Pex «изучить» его, найти несколько неудачных тестов, исправить код и так далее.

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

Я действительно в восторге от Пекса. Он предоставит тесты для случаев edege, о которых вы даже не догадываетесь, особенно если ваша команда небольшая и человек, пишущий методы, такой же, как и человек, пишущий тесты.

Это также обеспечит договорные обязательства, которым будут подчиняться ваши методы.

Если вы ищете литературу по написанию теорий (google David Saff), которые представляют собой более общий способ написания модульных тестов, и используете Pex в качестве исследователя теории, я обнаружил ступенчатое изменение производительности по сравнению с моим опытом. Я только что написал сообщение в блоге, в котором подробно описал свой опыт использования Pex в TDD, здесь: http://taumuon-jabuka.blogspot.com/2009/01/theory-driven-development-using_11.html

и как я уже сказал - я вижу это как TDD на стероидах! Он никоим образом не заменяет TDD, но увеличивает активность.

Разработка, ориентированная на тестирование, позволяет структурировать код для обеспечения возможности тестирования. В этом отношении Pex находит умные и неудобные пути в вашем коде, выходя за рамки простых показателей покрытия.

Основная сильная сторона Pex с Moles - это возможность отслеживания побочных эффектов при разработке Brownfield: один раз запустите Pex и сохраните выходные данные, затем примените изменения кода и снова запустите Pex, чтобы увидеть, что сломалось.