Comments 41
Круто! Django творит чудеса))
На всякий случай залил код на github. Просто запускайте
$ git clone git@github.com:svfat/habratest-bdd
Думал очередная, наивная статья: «как начать писать тесты» — ан нет!
Проект django-behave не поддерживается в данные момент, ищется мейнтейнер. Поддержки python 3 нет и не предвидится.
When I visit url "http://localhost:8081/"А как быть с тестовыми доменами? Или с продакшеном?
Уточните, не понимаю в чем проблема? Просто определяете этот шаг в steps.py как вам угодно, подтягиваете туда любые домены
Есть динамически генерируемые тестовые домены для каждой feature-ветки, есть просто альтернативные домены для сайта, и прочее. Как проверить текущий домен?
Более того, такие тесты не учитывают изменения в urls.py, и хотя тестируемые вьюхи не меняются — в тесте (насколько я понимаю) адрес прописан явно. Как это обойти?
Более того, такие тесты не учитывают изменения в urls.py, и хотя тестируемые вьюхи не меняются — в тесте (насколько я понимаю) адрес прописан явно. Как это обойти?
I don't always test my code But When I do, I do It in Production?
Вроде бы BDD (как и родные джанговские тесты) реальные домены использовать не должно никоим образом.
Вроде бы BDD (как и родные джанговские тесты) реальные домены использовать не должно никоим образом.
Я не тестирую на продакшене, я имитирую боевые условия, при которых для разных (под)доменах результат для вьюх — разный.
А руками вы как проверяете эти фичи? Обычно делаются поддомены для localhost или каким-то GET-параметром/кукой мокается домен, но это можно и в тестовый сценарий записать без проблем.
Руками я просто создаю поддомен на тестовом серваке с именем ветки, добавляю ее в Sites, и тестирую.
Более того, я считаю тестирование на локалхосте — ужасной ошибкой, поскольку есть разница в окружении между ним и боевым сервером (например разные версии системных библиотек и/или приложений, таких как libjpeg, например). Проще клонировать боевой сервер, и разворачивать тестирование на нем с использованием боевых данных (но закрыв, например, доступ к отправке почты).
Еретический метод — внесение абсолютно лишнего уровня абстракции.
Полностью «классические» тесты заменить на него не получится, а значит его использование в проекте только увеличит сложность поддержки (через добавление лишних сущностей и связей), не принося существенной пользы.
Полностью «классические» тесты заменить на него не получится, а значит его использование в проекте только увеличит сложность поддержки (через добавление лишних сущностей и связей), не принося существенной пользы.
Что значит «заменить классические тесты»? Мне кажется, все сильно зависит от цели тестирования.
UFO just landed and posted this here
Юнит-тесты (для которых Gherkin не годится) пишут все же не тестеры, зато Gherkin есть и для Руби, например. То есть, тестер сможет писать тесты для приложений хоть на Питоне, хоть на Руби, хоть еще на чем. По-моему, это даже не язык программирования, а что-то половинчатое, на уровне недо-блок-схемы, т.е. тестер может вообще не быть программистом, более того, в таком виде записать требования может хоть ПМ (а тест из требований получается сам собой).
Во многих случаях ваш подход тоже верен, но часто если можно попробовать упростить коллегам жизнь — почему бы этого не сделать.
Во многих случаях ваш подход тоже верен, но часто если можно попробовать упростить коллегам жизнь — почему бы этого не сделать.
UFO just landed and posted this here
К сожалению, простую человеческую речь часто можно понять неоднозначно, даже у человеков такая проблема, не говоря уже о железяках. Сейчас у компьютера есть большой плюс — он практически (по сравнению с человеком) не ошибается.
Особую печаль у того, кто будет смотреть в документацию, должен вызвать тот факт, что документации то никакой нет, мы просто привязываем какую-то фразу к питон коду (ещё не факт, что фраза эта будет грамотной и понятной). Возможно, конечно, в реальных проектах есть люди, которые умудряются кроме тестов писать ещё и исчерпывающую документацию как для пользователей, так и для разработчиков, но в основном наверняка нет.
Поэтому будет ещё круче:
— Лёх, а чо у меня тут, позырь, пожалуйста
— Ну открой сорцы, да глянь!
Поэтому будет ещё круче:
— Лёх, а чо у меня тут, позырь, пожалуйста
— Ну открой сорцы, да глянь!
Глобальная цель у тестирования одна — убедиться что поведение проекта соответствует спецификации (как бы она ни была выражена).
Использование BDD предполагает:
1. Введение в проект нового ЯП со своим синтаксисом и семантикой (а значит обучение им всех специалистов, работающих с тестами).
2. Дублирование части функционала, для возможности его использования в BDD.
3. Поддержка дублированного функционала (как только будет надо сделать какое-то новое действие, его надо замапить в правила).
Человек, который пишет тесты (а значит явно описывает требования спецификации ПО), должен быть в состоянии писать простейшие алгоритмы. Если он не может этого делать, то его нельзя допускать до этой работы. А если он может писать алгоритмы, то разницы между:
— user.create(name='test_name')
— «create user with name 'test_name'»
никакой нет, за тем исключением, что программистам будет проще разобрать 1-ый вариант, так как они его по 20 раз на дню видят.
Использование BDD предполагает:
1. Введение в проект нового ЯП со своим синтаксисом и семантикой (а значит обучение им всех специалистов, работающих с тестами).
2. Дублирование части функционала, для возможности его использования в BDD.
3. Поддержка дублированного функционала (как только будет надо сделать какое-то новое действие, его надо замапить в правила).
Человек, который пишет тесты (а значит явно описывает требования спецификации ПО), должен быть в состоянии писать простейшие алгоритмы. Если он не может этого делать, то его нельзя допускать до этой работы. А если он может писать алгоритмы, то разницы между:
— user.create(name='test_name')
— «create user with name 'test_name'»
никакой нет, за тем исключением, что программистам будет проще разобрать 1-ый вариант, так как они его по 20 раз на дню видят.
«Новый ЯП» это некоторый полу-формальный формат записи спецификаций, не более. Он не идеален, и если есть возможность, лучше спецификацию иметь отдельно от тестов, но возможность есть не всегда. Такая «спецификация-тест» для человека со стороны лучше, чем простой тест и никакой спецификации.
>«Новый ЯП» это некоторый полу-формальный формат записи спецификаций, не более.
И тем не менее ему надо учить всех людей, которые будут с ним взаимодействовать и большинство из которых точно может обойтись без него. Зачем тогда его вводить? Этот полу-формальный формат — отличный пример лишней сущности.
>Такая «спецификация-тест» для человека со стороны лучше, чем простой тест и никакой спецификации.
Простой тест и есть спецификация, причём максимально конкретная. Более того, простой тест более гибок, чем правила на специфичном для проекта ЯП, описывающем только часть (причём меньшую) предметной области.
Даже писать простые тесты с подробными комментариями на нормальном языке проще, чем поддерживать отдельный ЯП для описания этих тестов на «почти» нормальном языке.
Вообще, кто этот мифический «человек со стороны»?
И тем не менее ему надо учить всех людей, которые будут с ним взаимодействовать и большинство из которых точно может обойтись без него. Зачем тогда его вводить? Этот полу-формальный формат — отличный пример лишней сущности.
>Такая «спецификация-тест» для человека со стороны лучше, чем простой тест и никакой спецификации.
Простой тест и есть спецификация, причём максимально конкретная. Более того, простой тест более гибок, чем правила на специфичном для проекта ЯП, описывающем только часть (причём меньшую) предметной области.
Даже писать простые тесты с подробными комментариями на нормальном языке проще, чем поддерживать отдельный ЯП для описания этих тестов на «почти» нормальном языке.
Вообще, кто этот мифический «человек со стороны»?
Не-программист, не-разработчик. ПМ, например. Для него Питон это какие-то непонятные закорючки и скобочки, если прочесть их как-то можно, то написать практически нереально.
намного проще написать и понять, не будучи программистом чем
Зайдя на страницу товара 123
мы должны увидеть title намного проще написать и понять, не будучи программистом чем
result = self.client.get('/products/123/')
self.assert('title' in result.body)Буду рад увидеть здесь комментарий человека, который не понимает что написано в этих строках (и знает английский):
> result = self.client.get('/products/123/')
> self.assert('title' in result.body)
Человек, который работал в Excel, писал макросы для Word, настраивал что-нибудь в Jira, или ещё чего-нибудь похожее делал хоть раз в своей жизни, поймёт что тут написано. Это не говоря уже о том, что не ясно зачем ПМ-у вообще лезть в эти тесты.
Если же по какой-то неимоверной случайности этот ПМ вообще не сталкивался с программированием, то вот хороший повод узнать таки, чем он управляет.
> result = self.client.get('/products/123/')
> self.assert('title' in result.body)
Человек, который работал в Excel, писал макросы для Word, настраивал что-нибудь в Jira, или ещё чего-нибудь похожее делал хоть раз в своей жизни, поймёт что тут написано. Это не говоря уже о том, что не ясно зачем ПМ-у вообще лезть в эти тесты.
Если же по какой-то неимоверной случайности этот ПМ вообще не сталкивался с программированием, то вот хороший повод узнать таки, чем он управляет.
Погодите, я же объяснял выше — иногда, в некоторых командах, на некоторых проектах, надо не только прочесть, но и написать тоже. И удобно, когда сразу пишется и спецификация, и тест — а Gherkin гораздо больше похож на нормальную спецификацию, чем перегруженный служебными символами питоний код, вот и все. Написать текст с пятком ключевых слов проще, чем рабочий код на питоне, если изначально не знаешь ни того, ни другого.
UFO just landed and posted this here
Полезнее сделать максимальный объем работы максимально эффективно. Почитайте про то, откуда вообще появился BDD, он решает вполне конкретные проблемы TDD. Проблемы не то чтобы критичные, но если все будут думать по-вашему, движения не будет ни в какую сторону.
Есть прекрасные машинные коды, пускай все, кто хочет быть программистом, первым делом в них разбираются, иначе какие же они программисты? А как разберутся — пускай на них и пишут, зачем придумывать какие-то еще «языки высокого уровня».
Еще раз повторюсь: если вам не нужен BDD, это не значит, что он вообще никому не нужен.
Есть прекрасные машинные коды, пускай все, кто хочет быть программистом, первым делом в них разбираются, иначе какие же они программисты? А как разберутся — пускай на них и пишут, зачем придумывать какие-то еще «языки высокого уровня».
Еще раз повторюсь: если вам не нужен BDD, это не значит, что он вообще никому не нужен.
Это ведь тот же cucumber, который очень распространен в среде rails habrahabr.ru/post/62958/
А что этот человек в проекте-то делает?)
> ПМ, например
Гнать в шею ;)
Но в любом случае, наличие читабельной спецификации лучше чем ее отсутствие, правда? Я тут на досуге почитал всякие мысли про BDD — они еще правильно акцентируют внимание на том, что, собственно, тестируется. «Обычные» тесты на «обычном» ЯП подталкивают к юнит-тестированию, тестированию реализации, когда BDD «настраивает» на тестирование других вещей другими методами. В общем, реально разница некритичная, и в принципе можно всего того же добиться классическим TDD, но психологически сложнее. Программисты — ленивые сволочи в массе своей, и напрягаться не любят :)
Думаете, что увеличится сложность поддержки? Некоторые считают что чем больше тестов, тем проще поддерживать, так как все работает правильно. Меня очень удивило покрытие тестами кода 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.
Наворачивание ещё одного уровня абстракции (которым является BDD) над тестами увеличит сложность поддержки тестов.
Я ни в коем случае не говорил, что сами тесты — плохо, тесты — это хорошо, но только до тех пор, пока над ними не начинают ставить странные опыты.
Я ни в коем случае не говорил, что сами тесты — плохо, тесты — это хорошо, но только до тех пор, пока над ними не начинают ставить странные опыты.
UFO just landed and posted this here
В некоторых компаниях BDD является стандартом, в этом случае нет никакого дополнительного уровня абстракции, т.к. тесты просто будут писаться в другом стиле
Согласен, что такое может быть, но примеров не знаю совсем. Очень хочу посмотреть на чистые BDD тесты в большом проекте.
На счёт главного Вашего аргумента Gherkin — "лишний язык" в python проекте, мне кажется что вы погорячились…
Я не вообще против использования других языков, я против использования их конкретно в этом случае. Считаю, что язык эффективно занимается хорошим api.
Sign up to leave a comment.
BDD-разработка на django