Тест кейс в скрипте? Почему бы нет?
Автор Jackie, 03 апр 2005 14:26
Сообщений в теме: 10
#1
Отправлено 03 апреля 2005 - 14:26
Привет всем. У нас на работе поступило предложение записывать тест кейсы прямо в скрипты (в виде комментариев).
Хотелось бы обсудить этот вопрос.
С одной стороны, выгоды есть: Информация хранится в одном месте, облегчается доступ к ней, обеспечивается одновременное изменение скрипта и тест кейса. С другой стороны, скрипт становится перегруженным комментариями. Лично мне идея не очень... Но может, я просто слишком привык к тому, что "котлеты должны быть отдельно, а мухи отдельно"?:)
Хотелось бы узнать ваше мнение.
Спасибо.
Хотелось бы обсудить этот вопрос.
С одной стороны, выгоды есть: Информация хранится в одном месте, облегчается доступ к ней, обеспечивается одновременное изменение скрипта и тест кейса. С другой стороны, скрипт становится перегруженным комментариями. Лично мне идея не очень... Но может, я просто слишком привык к тому, что "котлеты должны быть отдельно, а мухи отдельно"?:)
Хотелось бы узнать ваше мнение.
Спасибо.
#2
Отправлено 04 апреля 2005 - 07:45
Я считаю, если есть время на добавление комментариев, то почему бы и нет? Это должно быть достаточно удобно. Но тогда надо ввести это правило для всей фирмы.
#3
Отправлено 04 апреля 2005 - 09:24
Я-бы порекомендовал следующее: сделать пару-тройку примеров, собрать коротенький митинг, обсудить с народом и принять решение - удобно-ли при таком подходе работать или нет.
#4
Отправлено 04 апреля 2005 - 09:55
Я вижу только один "нет".
Как делать оценку покрытия тест кейсами юз кейсов, если тест кейсы не собраны в документ и не замаплены на юз кейс?
Второе "но" тесно связано с первым: как отслеживать версионность тест кейсов, как знать какие тест кейсы должны быть пересмотрены/переделаны если изменились требования (юз кейсы)?
Более общий вопрос: а зачем держать вместе код и документ? Две разные сущности, как по мне, должны хранится отдельно. Я не протв комментаириев, но комментарий не документ (пусть меня перекрасят поклонники ХР).
Как делать оценку покрытия тест кейсами юз кейсов, если тест кейсы не собраны в документ и не замаплены на юз кейс?
Второе "но" тесно связано с первым: как отслеживать версионность тест кейсов, как знать какие тест кейсы должны быть пересмотрены/переделаны если изменились требования (юз кейсы)?
Более общий вопрос: а зачем держать вместе код и документ? Две разные сущности, как по мне, должны хранится отдельно. Я не протв комментаириев, но комментарий не документ (пусть меня перекрасят поклонники ХР).
Слава Панкратов
Редактор портала www.it4business.ru
Редактор портала www.it4business.ru
#5
Отправлено 05 апреля 2005 - 05:40
В какой цвет будут красить Кейса?
При определённом формате комментариев они элементарно выделяются в отдельныи документы...
Всё новое - это давно забытое старое (забытое но не всеми и не везде)...
ИМХО, можно и при этом не сложно сделать свой формат комментариев, в котором обеспечивалась бы после его выделения из кода связь с внешними документами (оговорите для себя формат тегов в комментариях).
При определённом формате комментариев они элементарно выделяются в отдельныи документы...
Всё новое - это давно забытое старое (забытое но не всеми и не везде)...
ИМХО, можно и при этом не сложно сделать свой формат комментариев, в котором обеспечивалась бы после его выделения из кода связь с внешними документами (оговорите для себя формат тегов в комментариях).
#6
Отправлено 05 апреля 2005 - 08:07
Я предпочитаю зелёный :)
То есть сначала сохраняем две разные сущности в одну, чтобы потом выделять и анализировать? Мне вегда "нравился" этот подход.
То есть сначала сохраняем две разные сущности в одну, чтобы потом выделять и анализировать? Мне вегда "нравился" этот подход.
Слава Панкратов
Редактор портала www.it4business.ru
Редактор портала www.it4business.ru
#7
Отправлено 05 апреля 2005 - 08:48
Оранжевый нынче популярен кстати,
но ведь хорошо документированный код с правильной организацией комментариев требует гораздо меньше времени при дальшейшей его поддержке, никто не мешает заранее оговорить правило написание таких комментариев... и когда они поймут что хотят менять - меняться будет только код, а не документация-код-документация (с возможностью непонимания в тех местах где у меня дефис ;))... + после исправлений проще будет обнавлять остальную документацию... "скомпилировал код", "скомпилировал доки" :)
но ведь хорошо документированный код с правильной организацией комментариев требует гораздо меньше времени при дальшейшей его поддержке, никто не мешает заранее оговорить правило написание таких комментариев... и когда они поймут что хотят менять - меняться будет только код, а не документация-код-документация (с возможностью непонимания в тех местах где у меня дефис ;))... + после исправлений проще будет обнавлять остальную документацию... "скомпилировал код", "скомпилировал доки" :)
#8
Отправлено 05 апреля 2005 - 13:26
Экономия времени на создание артефакта в фазе кодирования перекроется затратами времени на создание артефакта когда это будет надо. Я не спорю, что можно и в коде, если документа не надо или нет необходимости делать то о чём я писал выше.
Слава Панкратов
Редактор портала www.it4business.ru
Редактор портала www.it4business.ru
#9
Отправлено 05 апреля 2005 - 16:18
Я только имел ввиду, что небольшой свой тул (на создание такого парсера неделя*программист - максимум, с тестированием и написанием правила оформления комментариев) даст возможность иметь каждый раз одновременно с компиляцией тестов обновлённые документ по тестам с любыми внешними связями(реализованными за счёт тэгов определённого формата включаемых в комментарии), и по этим связям можно будет отслеживать например необходимость изменений, которая будет отмечаться во внешнем статическом(редактируемым пользователем) документе и может обнаруживаться на стадии связывания или после (я так понял это нужно)...
Затраты времени на получение обновлённого документа - ноль (не считая процессорного времени на работу парсера), не это ли цель автоматизации?
пример
текст программы теста:
//<link="тест ЧВ-001.11_01_2005">
//проверяем по очереди пальци человека на правильность написанных на них названий
функция проверять (){}...
внеший документ:
до изменения
<link="тест ЧВ-001.11_01_2005">
на всех пальцах человека есть написанные названия
после изменения
<link="тест ЧВ-001.05_04_2005">
на всех пальцах человека есть номера
в случаи соответствия дат в ссылках после компиляции документа мы можем, возможно, ещё туда приделать вывод выполненного теста и получить связь задание_на_тестирование - набор_тестов - результаты
в случаи несоответствия дат в ссылках на этапе компиляции выдаётся информация о изменении требований...
ЗЫ. кстати идея пока бесплатныя и нереализованная ;(
ЗЗЫ. даже если бы я её объявил платной, все бы, кто захотел, всё равно могли бы её взять бесплатно ;( а обидно
Затраты времени на получение обновлённого документа - ноль (не считая процессорного времени на работу парсера), не это ли цель автоматизации?
пример
текст программы теста:
//<link="тест ЧВ-001.11_01_2005">
//проверяем по очереди пальци человека на правильность написанных на них названий
функция проверять (){}...
внеший документ:
до изменения
<link="тест ЧВ-001.11_01_2005">
на всех пальцах человека есть написанные названия
после изменения
<link="тест ЧВ-001.05_04_2005">
на всех пальцах человека есть номера
в случаи соответствия дат в ссылках после компиляции документа мы можем, возможно, ещё туда приделать вывод выполненного теста и получить связь задание_на_тестирование - набор_тестов - результаты
в случаи несоответствия дат в ссылках на этапе компиляции выдаётся информация о изменении требований...
ЗЫ. кстати идея пока бесплатныя и нереализованная ;(
ЗЗЫ. даже если бы я её объявил платной, все бы, кто захотел, всё равно могли бы её взять бесплатно ;( а обидно
#10
Отправлено 05 апреля 2005 - 18:39
Всё можно уважаемый. Кроме того есть инструменты, которые вытаскивают из кода комментарии и в зависимости от тэгов строить к примеру релиз-ноты или тест кейсы. Я только не могу понять зачем сначала хранить две разные по сути вещи в одном месте, с тем чтобы потом их оттуда выцарапывать с помощью внешнего парсера. Кроме того если использовать тэги - получаются уже не совсем комментарии, а пусть простейший, но код. Зачем?
Слава Панкратов
Редактор портала www.it4business.ru
Редактор портала www.it4business.ru
#11
Отправлено 07 апреля 2005 - 08:19
Большое спасибо всем, кто принял участие в обсуждении.
Ваши мнения будут доведены до коллектива. Надеюсь, это поможет принять нам правильное решение.
:)
Ваши мнения будут доведены до коллектива. Надеюсь, это поможет принять нам правильное решение.
:)
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных