BDD-разработка на django

[@Artemis4You]

Круто! Django творит чудеса))

[@svfat]

На всякий случай залил код на github. Просто запускайте

$ git clone [e-mail]:svfat/habratest-bdd

чтобы получить копию

[@Artemis4You]

Спасибо посмотрю

[@Duke565]

Думал очередная, наивная статья: «как начать писать тесты» — ан нет!

[@kmmbvnr]

Проект django-behave не поддерживается в данные момент, ищется мейнтейнер. Поддержки python 3 нет и не предвидится.

[@svfat]

Это так. Я написал в начале о проблемах несовместимости. В своем форке я корявенько пофиксил их. Что-то посоветуете?

[@svfat]

Уточните, не понимаю в чем проблема? Просто определяете этот шаг в steps.py как вам угодно, подтягиваете туда любые домены

[@svfat]

По второму вопросу: ведь адрес можно доставать из urls.py с помощью django.core.urlresolvers.reverse. Первый вопрос, я, если честно до конца не понял, но думаю можно генерировать имена доменов аналогично тому, как генерируются они в вашем приложении.

[@ilvar]

I don't always test my code But When I do, I do It in Production?

Вроде бы BDD (как и родные джанговские тесты) реальные домены использовать не должно никоим образом.

[@ilvar]

А руками вы как проверяете эти фичи? Обычно делаются поддомены для localhost или каким-то GET-параметром/кукой мокается домен, но это можно и в тестовый сценарий записать без проблем.

[@Tiendil]

Еретический метод — внесение абсолютно лишнего уровня абстракции.

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

[@ilvar]

Что значит «заменить классические тесты»? Мне кажется, все сильно зависит от цели тестирования.

[@ilvar]

Юнит-тесты (для которых Gherkin не годится) пишут все же не тестеры, зато Gherkin есть и для Руби, например. То есть, тестер сможет писать тесты для приложений хоть на Питоне, хоть на Руби, хоть еще на чем. По-моему, это даже не язык программирования, а что-то половинчатое, на уровне недо-блок-схемы, т.е. тестер может вообще не быть программистом, более того, в таком виде записать требования может хоть ПМ (а тест из требований получается сам собой).

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

[@ilvar]

К сожалению, простую человеческую речь часто можно понять неоднозначно, даже у человеков такая проблема, не говоря уже о железяках. Сейчас у компьютера есть большой плюс — он практически (по сравнению с человеком) не ошибается.

[@xfenix]

Особую печаль у того, кто будет смотреть в документацию, должен вызвать тот факт, что документации то никакой нет, мы просто привязываем какую-то фразу к питон коду (ещё не факт, что фраза эта будет грамотной и понятной). Возможно, конечно, в реальных проектах есть люди, которые умудряются кроме тестов писать ещё и исчерпывающую документацию как для пользователей, так и для разработчиков, но в основном наверняка нет.
Поэтому будет ещё круче:
— Лёх, а чо у меня тут, позырь, пожалуйста
— Ну открой сорцы, да глянь!

[@Tiendil]

Глобальная цель у тестирования одна — убедиться что поведение проекта соответствует спецификации (как бы она ни была выражена).

Использование BDD предполагает:

1. Введение в проект нового ЯП со своим синтаксисом и семантикой (а значит обучение им всех специалистов, работающих с тестами).
2. Дублирование части функционала, для возможности его использования в BDD.
3. Поддержка дублированного функционала (как только будет надо сделать какое-то новое действие, его надо замапить в правила).

Человек, который пишет тесты (а значит явно описывает требования спецификации ПО), должен быть в состоянии писать простейшие алгоритмы. Если он не может этого делать, то его нельзя допускать до этой работы. А если он может писать алгоритмы, то разницы между:

— user.create(name='test_name')
— «create user with name 'test_name'»

никакой нет, за тем исключением, что программистам будет проще разобрать 1-ый вариант, так как они его по 20 раз на дню видят.

[@ilvar]

«Новый ЯП» это некоторый полу-формальный формат записи спецификаций, не более. Он не идеален, и если есть возможность, лучше спецификацию иметь отдельно от тестов, но возможность есть не всегда. Такая «спецификация-тест» для человека со стороны лучше, чем простой тест и никакой спецификации.

[@Tiendil]

>«Новый ЯП» это некоторый полу-формальный формат записи спецификаций, не более.
И тем не менее ему надо учить всех людей, которые будут с ним взаимодействовать и большинство из которых точно может обойтись без него. Зачем тогда его вводить? Этот полу-формальный формат — отличный пример лишней сущности.

>Такая «спецификация-тест» для человека со стороны лучше, чем простой тест и никакой спецификации.
Простой тест и есть спецификация, причём максимально конкретная. Более того, простой тест более гибок, чем правила на специфичном для проекта ЯП, описывающем только часть (причём меньшую) предметной области.

Даже писать простые тесты с подробными комментариями на нормальном языке проще, чем поддерживать отдельный ЯП для описания этих тестов на «почти» нормальном языке.

Вообще, кто этот мифический «человек со стороны»?

[@ilvar]

Не-программист, не-разработчик. ПМ, например. Для него Питон это какие-то непонятные закорючки и скобочки, если прочесть их как-то можно, то написать практически нереально.

Зайдя на страницу товара 123 мы должны увидеть title

намного проще написать и понять, не будучи программистом чем

result = self.client.get('/products/123/') self.assert('title' in result.body)

[@Tiendil]

Буду рад увидеть здесь комментарий человека, который не понимает что написано в этих строках (и знает английский):

> result = self.client.get('/products/123/')
> self.assert('title' in result.body)

Человек, который работал в Excel, писал макросы для Word, настраивал что-нибудь в Jira, или ещё чего-нибудь похожее делал хоть раз в своей жизни, поймёт что тут написано. Это не говоря уже о том, что не ясно зачем ПМ-у вообще лезть в эти тесты.

Если же по какой-то неимоверной случайности этот ПМ вообще не сталкивался с программированием, то вот хороший повод узнать таки, чем он управляет.

[@ilvar]

Погодите, я же объяснял выше — иногда, в некоторых командах, на некоторых проектах, надо не только прочесть, но и написать тоже. И удобно, когда сразу пишется и спецификация, и тест — а Gherkin гораздо больше похож на нормальную спецификацию, чем перегруженный служебными символами питоний код, вот и все. Написать текст с пятком ключевых слов проще, чем рабочий код на питоне, если изначально не знаешь ни того, ни другого.

[@ilvar]

Полезнее сделать максимальный объем работы максимально эффективно. Почитайте про то, откуда вообще появился BDD, он решает вполне конкретные проблемы TDD. Проблемы не то чтобы критичные, но если все будут думать по-вашему, движения не будет ни в какую сторону.

Есть прекрасные машинные коды, пускай все, кто хочет быть программистом, первым делом в них разбираются, иначе какие же они программисты? А как разберутся — пускай на них и пишут, зачем придумывать какие-то еще «языки высокого уровня».

Еще раз повторюсь: если вам не нужен BDD, это не значит, что он вообще никому не нужен.

[@Ant0ha]

Это ведь тот же cucumber, который очень распространен в среде rails habrahabr.ru/post/62958/

[@ilvar]

> ПМ, например

[@ilvar]

Но в любом случае, наличие читабельной спецификации лучше чем ее отсутствие, правда? Я тут на досуге почитал всякие мысли про BDD — они еще правильно акцентируют внимание на том, что, собственно, тестируется. «Обычные» тесты на «обычном» ЯП подталкивают к юнит-тестированию, тестированию реализации, когда BDD «настраивает» на тестирование других вещей другими методами. В общем, реально разница некритичная, и в принципе можно всего того же добиться классическим TDD, но психологически сложнее. Программисты — ленивые сволочи в массе своей, и напрягаться не любят :)

[@svfat]

Думаете, что увеличится сложность поддержки? Некоторые считают что чем больше тестов, тем проще поддерживать, так как все работает правильно. Меня очень удивило покрытие тестами кода sqlite.

As of version 3.8.0, the SQLite library consists of approximately 84.3 KSLOC of C code. (KSLOC means thousands of «Source Lines Of Code» or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 1084 times as much test code and test scripts — 91452.5 KSLOC.

[@Tiendil]

Наворачивание ещё одного уровня абстракции (которым является BDD) над тестами увеличит сложность поддержки тестов.
Я ни в коем случае не говорил, что сами тесты — плохо, тесты — это хорошо, но только до тех пор, пока над ними не начинают ставить странные опыты.

[@Tiendil]

В некоторых компаниях BDD является стандартом, в этом случае нет никакого дополнительного уровня абстракции, т.к. тесты просто будут писаться в другом стиле
Согласен, что такое может быть, но примеров не знаю совсем. Очень хочу посмотреть на чистые BDD тесты в большом проекте.

На счёт главного Вашего аргумента Gherkin — "лишний язык" в python проекте, мне кажется что вы погорячились…
Я не вообще против использования других языков, я против использования их конкретно в этом случае. Считаю, что язык эффективно занимается хорошим api.