TDD в Python 3.1 - PullRequest
       49

TDD в Python 3.1

2 голосов
/ 15 марта 2011

Я программист C ++, который работает через TDD.Сейчас я изучаю Python 3 и хочу продолжить работу с TDD.На данный момент в C ++ я даю интерфейс всем своим классам и создаю их версии.Затем я передаю указатели на эти интерфейсы в своем коде.

Я хотел бы знать, какие библиотеки мне следует использовать, чтобы эффективно использовать tdd в python.Что входит в состав Python и какие дополнения мне нужны.Я нашел это, и это кажется очень интересным:

http://www.voidspace.org.uk/python/mock/

Какие альтернативы стоит также изучить?

Какие онлайн-ресурсы, онлайн-учебники или книги стоит проверить?

Спасибо!

Ответы [ 3 ]

6 голосов
/ 15 марта 2011

Я никогда не находил необходимости ни в чем, кроме того, что предоставляет python.

Из-за написания Duck в Python очень и очень легко создавать объекты Mock с минимальной реализациейи затем прочитайте, что в них, чтобы проверить ваши утверждения.

Я считаю, что модуль unittest прекрасно работает и для меня.

1 голос
/ 15 марта 2011

Библиотека макетов широко используется для макетов (хотя есть и множество других библиотек-макетов, и часто вам вообще не нужно имитировать). Также распространено использование одного из testrunner, nose, pytest, zope.testrunner или одного из Distribute.

0 голосов
/ 17 марта 2011

В последнее время я сам на них смотрю, нос [1] рекламирует себя как python tdd framework, mock, mox и большинство других mock-библиотек для python, похоже, не подходят мне. Я не совсем уверен, что издеватели действительно нужны. Как упомянуто ранее, типизация утки в Python очень гибкая, просто создайте базовый класс и верните ему значения, которые вы хотите / ожидаете. Но в то же время у вас будет много заглушек. Эта ложная библиотека, mocker [1], кажется, имеет смысл для меня, но все еще не использует ее.

В моем недавнем опыте unittest (часть std lib Python) и заглушки, кажется, отвечают всем требованиям. Я просто рисую интерфейс, который вызывает NotImplementedError для каждого метода, затем расширяю его в моем тестовом интерфейсе (макет mock-объекта), который возвращает ожидаемые / неожиданные результаты, и расширяю интерфейс для моих классов, которые я хочу реализовать. Я не продал это решение, я думаю, что патч-декоратор может быть хорошим для этого. В python интерфейсы обычно называются классами MixIn.

[1] http://somethingaboutorange.com/mrl/projects/nose/1.0.0/ [2] http://labix.org/mocker

...