Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск | FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи | Книги | Новости VCL |
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник |
Коллекция курьезных вопросов из форумов
KOL и MCK |
KOL и MCK - Компактные программы на Delphi
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.ru

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »

DelphiSpec


Kerk ©   (18.12.13 20:27

Рискну и создам ветку про Delphi :)

Хочу порекламировать альфа-версию библиотеки DelphiSpec. Фактически ее можно воспринимать как Delphi-реализацию языка Gherkin.

Цель библиотеки состоит в том, что она дает возможность описывать сценарии работы системы и затем эту систему на соответствие этим сценариям проверять. Позволяя использовать Behavior-Driven Development при разработке программ на Delphi.

Подробнее по ссылке:
http://roman.yankovsky.me/?p=1258


Rouse__   (18.12.13 21:50[1]

UML для начинающих, по сути?


DVM ©   (18.12.13 21:52[2]

Необычная штука. Правда мало информации.


Пит   (19.12.13 00:20[3]

разбирался 3 минуты. Не разобрался, не понял.

Прикольно было бы, если Kerk освоил инфографику ;)


Kerk ©   (19.12.13 00:20[4]


> Rouse__   (18.12.13 21:50) [1]

UML - это все-таки не то. UML - штука абстрактная, а сценарии - штуки конкретные.

К тому же человек нетехнический про UML даже думать не станет, а вот обучить его писать сценарии вроде такого вполне можно:

Допустим я нахожусь в окне входа в систему
    И существует пользователь с именем "Roman" и паролем "123"
Когда я ввожу имя "Roman" и пароль "123"
Тогда я имею доступ к личному профайлу пользователя "Roman"
    А также я имею доступ к личным сообщениям пользователя "Roman"

 

> DVM ©   (18.12.13 21:52) [2]

Я пока даже README нормальный не успел написать. Общую информацию о Gherkin можно поискать в интернете, а DelphiSpec еще только в самом начале своего развития, надеюсь постепенно будет информацией обрастать.


картман ©   (19.12.13 03:18[5]

кто будет пользователем данной библиотеки?


Kerk ©   (19.12.13 09:15[6]


> а вот обучить его писать сценарии

А главное - ЧИТАТЬ. Такой сценарии сможет прочитать любой адекватный человек. А вот UML-диаграмму понять или даже код юнит-теста...

> картман ©   (19.12.13 03:18) [5]
>
> кто будет пользователем данной библиотеки?

Ну пользователем библиотеки по определению может быть только программист.


Kerk ©   (19.12.13 12:22[7]

> кто будет пользователем данной библиотеки?

Gherkin позволяет на почти человеческом языке высокоуровнего описывать функционал приложения. И такое описание может является одновременно и частью постановки задачи, и документацией, и тестом (благодаря DelphiSpec).


Pavia ©   (19.12.13 15:23[8]

Не взлетит.


DevilDevil ©   (19.12.13 16:05[9]

Хотелось бы скриншотики, примерчики, описания
А то не понятно


Kerk ©   (19.12.13 16:30[10]

Ох. Реально многим непонятно. Кто-нибудь пальцем ткнет в место, которое непонятно? Я действительно не понимаю, что же здесь непонятного... Возможно, нахожусь в контексте и какие-то детали кажутся очевидным.

Примерчиками, описаниями оно обрастет постепенно. Я ж не человек-комбайн, что успел, то успел :)


Pavia ©   (19.12.13 17:28[11]

Всё очень просто и понятно. Очередной специализированный язык.
Коих ещё в 70-тых насчитывалось более двух тысяч.
Так как язык не узко направленный то нишу он не завоюет. Нужен мега пиар.

А копировать строчку "теперь программировать может человек не владеющим программированием" - через чур заезжена. Не ну её богу, SQL, UML, BY, и прочие использовали эту фразу. Да и Fortran если не путаю так начинался.

Единственно отличия от большинства высокоурожайный язык.  Но почему-то такие языки как-то не сыскали популярности.


Kerk ©   (19.12.13 17:31[12]


> Pavia ©   (19.12.13 17:28) [11]

Юмор в том, что нишу Gherkin уже завоевал. Про него даже книжки есть. В BDD это фактически стандарт.


DevilDevil ©   (19.12.13 17:49[13]

Всё ясно
Успехов в развитии!
Сам подобные системы не использую, но это скорее мой минус. Респект и уважуха


brother ©   (19.12.13 18:05[14]

Так теперь будем программировать мега макросами? Нееее, не взлетит имхо.


Пит   (19.12.13 18:31[15]

Самый мой успешный проект - когда _все_ вокруг говорили, что это фигня и никому не нужно. Ни один человек не высказался за.

Так что вперед, ЯР ;)


Kerk ©   (20.12.13 00:25[16]

Да я не ждал оваций.

Вот всеобщее непонимание на этом форуме удивило. В англоязычном сообществе люди быстро сориентировались, первый же комментарий: "Neat! We use Gherkin under C# and it is nice that it could be used under Delphi now".

Возможно, я действительно непонятно всю свою затею описал. Но в самом блоге положительная реакция все-таки есть. Ну ладно, пусть это будет моя вина, я плохой рассказчик - это правда.


Пит   (20.12.13 02:59[17]


> Вот всеобщее непонимание на этом форуме удивило

ламеры, видимо


> я плохой рассказчик - это правда.

это правда


KilkennyCat ©   (20.12.13 10:09[18]

Я ваще ниче не понял. И самое главное непонятное - а зачем еще один какой-то язык? А че мне делать с остальными? Не, если конечно, для этого есть ниша, и он ее завоевал, и даже стандарт - это хорошо. Наверное. Но все-таки, чисто практически, нафига долго писать словами авторизацию, если можно просто if a = b then ? и просто, и главное - однозначно. А если это ради обычных пользователей, то обычный пользователь не языка не понимает, а идеологии.


Kerk ©   (20.12.13 12:36[19]


> KilkennyCat ©   (20.12.13 10:09) [18]

Нормальную авторизацию (a=b) тебе все равно придется писать. Сценарий лишь описывает с точки зрения пользователя, что в этот момент происходит. Твой код авторизации поймешь только ты, а сценарий поймет твой начальник, заказчик и твоя девушка. И как бесплатный бонус ты этот сценарий с помощью DelphiSpec сможешь превратить в юнит-тесты и не уставать убеждаться, что программа действительно работает так, как предполагалось.

Сценарии упрощают взаимодействие между тобой (как человеком, понимающим КАК работает программа) и людьми, которые знают ЧТО она должна делать. Им даже не обязательно уметь писать такие сценарии, им достаточно уметь их читать, чтобы убедиться, что постановку задачи ты понимаешь правильно. А затем уже ты с помощью DelphiSpec убедишься, что все их требования действительно реализованы.

Вот взять например комментарий из блога: Это действительно круто, наконец-то от требований к тестам всего один шаг — формализовать требования в виде сценария… (ну и со стороны программы предоставить API)

Или посмотреть на отзывы к вдохновившему меня проекту Cucumber (там внутри тот же Gherkin):

    A major contributory factor to the success of the BBC's digital Olympics was the use of Cucumber to collaboratively specify requirements, guide development, drive automated tests and describe the system.

—Aidy Lewis, Test Discipline Lead BBC Future Media - News and Knowledge


Если и так не понятно, то помогите мне уже донести мысль, ткните пальцем в конкретное непонятное место.


Kerk ©   (20.12.13 13:26[20]

Позволю себе процитировать еще один отзыв о DelphiSpec из англоязычного сообщества:

I totally love that! I was thinking about doing something like this when I added support for testcase attributes.
However to get this more similar to Cucumber I would suggest adding a third level to the DUnit test hierarchy to see how a scenario was defined and what step failed.

Так что я действительно вас прошу не отмахиваться "ненужный очередной язык, не взлетит". Очень многим это действительно не нужно, но вы все равно пустите эти идеи в свою душу, как минимум они достойны внимания.


KilkennyCat ©   (20.12.13 13:56[21]


> Kerk ©   (20.12.13 12:36) [19]

Ага, спасибо. Теперь ясно. Вся фишка в том, что в реалии я сразу начну писать a=b, получив от начальника, заказчика и девушки нечто типа: "я хочу... э..."


jumping jack   (20.12.13 14:02[22]

> текст на предметно-ориентированном языке могут писать и — главное — читать эксперты предметной области, а вовсе не программисты.

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

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

как насчет "Delphi/Pascal --> Gherkin"? ;^)


jumping jack   (20.12.13 14:09[23]

>"Delphi/Pascal --> Gherkin"
можно же взять только специфическое подмножество паскаля
просто чтобы упростить для старых "пасквилянтов" этап обучения и - немаловажно - минимизировать число набираемых ими символов


Inovet ©   (20.12.13 15:05[24]

> [22] jumping jack   (20.12.13 14:02)
> как насчет «Delphi/Pascal —-> Gherkin»? ;^)

Так умер же.


jumping jack   (20.12.13 15:21[25]

> Так умер же
как древнегреческий с латынью?
тем более здорово, если "литературное наследие" перевести на более живые можно будет автоматически


Kerk ©   (20.12.13 20:34[26]


> jumping jack   (20.12.13 14:02) [22]
> как насчет "Delphi/Pascal --> Gherkin"? ;^)

О подобном Александр Люлин много пишет, у него там "переходники" между user-friendly скриптами и Delphi-кодом полуавтоматически генерируются:

http://programmingmindstream.blogspot.ru/2013/12/delphispec_20.html

Это все интересно, но по-моему DelphiSpec проще :)


Kerk ©   (22.12.13 21:34[27]

Сделал поддержку такой фантастической фичи Gherkin, как data table. Теперь можно писать такие сценарии:

Feature: Accounts

Scenario: Correct Login
 Given users exists:
   | id | name    | password |
   | 1  | Roman  | pass1      |  
   | 2  | Other   | pass2      |
 When I login with "Roman" and "pass1"
 Then I have access to private messages

Scenario: Incorrect Login
 Given users exists:
   | id | name   | password |
   | 1  | Roman | pass1      |  
   | 2  | Other  | pass2      |
 When I login with "Roman" and "pass2"
 Then access denied


(ссылка на тот случай, если форматирование поедет https://github.com/RomanYankovsky/DelphiSpec/blob/master/Demo/Features/accounts.feature)

Причем в итоге это все автоматически превратиться в параметр нужного типа.

   TUserInfo = record
     Name: string;
     Password: string;
     Id: Integer;
   end;

   procedure Given_users_exists(Table: TArray<TUserInfo>);

(полный код примера https://github.com/RomanYankovsky/DelphiSpec/blob/master/Demo/SampleAccountsStepDefs)

Саму возможность задавать названия шагов не в аттрибутах, а прямо в имени метода (Given_users_exists) добавил Стефан Глинке, за что ему огромная благодарность. Хорошая идея. Так же он подправил код для работы в старых (начиная с XE) версиях Delphi и добавил поддержку массивов, благодаря чему можно писать подобные сценарии:

Scenario: Add number
 Given a list of numbers 1,2,3,4,5
 When I add number 7
 Then Count should be 6
   And list content should be 1,2,3,4,5,7


В общем, проект быстро развивается. Я доволен как слон :)


Kerk ©   (22.12.13 21:34[28]


> (полный код примера https://github.com/RomanYankovsky/DelphiSpec/blob/master/Demo/SampleAccountsStepDefs)


https://github.com/RomanYankovsky/DelphiSpec/blob/master/Demo/SampleAccountsStepDefs.pas


antonn ©   (22.12.13 21:53[29]


> Ох. Реально многим непонятно. Кто-нибудь пальцем ткнет в
> место, которое непонятно?

я пару раз перечитал тему, но мне не понятно - зачем оно нужно? :) в реальной разработке. Когда ТЗ формирует один сервис (на своем уровне интерфейс-фунционал не вдаваясь в детали реализации), а реализацию - допустим я и еще кто-то, документацию пользователю пишет третий совместно с сервисом поставившим задачу на реализацию. Каким образом эти сценарии могут помочь и кто их должен будет писать?


Kerk ©   (22.12.13 21:57[30]


> antonn ©   (22.12.13 21:53) [29]

Позволю себе не отвечать (раз уж не получается в который раз), а дать ссылку на неплохую статью:
http://habrahabr.ru/company/etnasoft/blog/166747/


antonn ©   (22.12.13 22:18[31]

Какой-то идеальный мир разработчика, в котором появился еще одна профессия типа "эффективный менеджер", но только программист, имхо.
Это применимо для огромных проектов? Ну вот читал я http://habrahabr.ru/post/182160/ , написано как настроить, это ж отдельная область с которой нужно разбираться, которую нужно правильно употреблять (например я написал сайт, аутентификация и запрос данных, фильтры - это все нужно будет описывать в юнит-тестах, разве это не растянет разработку на более долгий срок?), в конце концов это еще одно звено.


картман ©   (22.12.13 22:27[32]


> http://habrahabr.ru/company/etnasoft/blog/166747/

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


Допустим я нахожусь в окне входа в систему
    И существует пользователь с именем "Roman" и паролем
"123"
Когда я ввожу имя "Roman" и пароль "123"
Тогда я имею доступ к личному профайлу пользователя "Roman"
    А также я имею доступ к личным сообщениям пользователя
"Roman"


а не


Допустим я нахожусь в окне входа в систему
    И существует пользователь с именем "Roman" и паролем
"123"
Когда я ввожу имя "Roman" и пароль "123"
Тогда я имею доступ к личному профайлу пользователя "Roman"
    А также я не имею доступ к личным сообщениям пользователя
"Roman"


? Где описывается этот кусок предметной области?


antonn ©   (22.12.13 22:28[33]

Точнее я что хочу спросить... реально есть профит в сабже, особенно когда выполнить надо оптимально в контексте сжатых сроков (читай - костыли и сопли будут (разумеется на стабильность не влияющие), вопрос в их количестве)?
Ну вот для примера есть софт, скрин который я уже показывал ( http://antonn.com/fh/store/1on45pf3.png ). Это модуль для большой корпоративной системы, тупая мониторилка с опросом весов и возможностью их прогрузки. Насколько я понял, сабж описывает поведение на определенную реакцию (не уверен что объясняю не коряво), вот для подобного модуля (написанного почти с нуля) юнит тест будет каким объемом и сколько времени может занять его подготовка по сравнению с разработкой?


Kerk ©   (22.12.13 22:40[34]


> картман ©   (22.12.13 22:27) [32]

Предметная область как правило лежит в голове заказчиков, бизнес-аналитиков и т.п. (нужно подчеркнуть). Именно благодаря тому, что спецификация написана на естественном языке (почти), вышеперечисленные категории граждан своими глазами могут убедиться, что она написана верно.

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


> antonn ©   (22.12.13 22:28) [33]

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

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

Но я бы не хотел, чтобы эта ветка переходила во что-то вроде "о пользе тестирования".


Kerk ©   (22.12.13 22:44[35]

Я люблю сравнивать статическую типизацию и тесты. Как вы знаете, есть много языков без статической типизации. Вот то время, которое вы в Delphi тратите на описание типов, оно окупается? Не раздражает эта необходимость на подобную ерунду время тратить? Реально же мешает код писать. Какой реально есть профит в статической типизации, особенно когда выполнить надо оптимально в контексте сжатых сроков?

:)


silver ©   (22.12.13 22:50[36]

Роман, поставь себя на место заказчика
будешь ты писать ТЗ в терминах этого языка?


Kerk ©   (22.12.13 22:55[37]


> silver ©   (22.12.13 22:50) [36]
>
> Роман, поставь себя на место заказчика
> будешь ты писать ТЗ в терминах этого языка?

Конечно не буду. Заказчик и ТЗ-то как правило написать не способен, приходится с ним специально обученным людям нянчиться и клещами детали вытаскивать :)

Но как я уже неоднократно говорил, основной профит не в том, что такие сценарии могут писать непрограммисты (это круто, но не основное), основной профит в том, что простые люди могут такие сценарии ЧИТАТЬ. Тот же программист прочитав ТЗ, может накидать таких сценариев и показать их бизнес-аналитику, чтоб получить добро, а затем они автоматически превратятся в юнит-тесты.


antonn ©   (22.12.13 23:03[38]


> Как вы знаете, есть много языков без статической типизации.
>  Вот то время, которое вы в Delphi тратите на описание типов,
>  оно окупается? Не раздражает эта необходимость на подобную
> ерунду время тратить?

я пишу в дельфи7, vs2008-12, eclipse, и там как бы написать "private int Count" вообще надо меньше секунды, ну в крайнем случае секунд пять (особенно с больными на голову студиями и языками в которых есть регистрозависимость). Зато как раз явное указание типа, как и продуманность архитектуры в целом, сильно сократит рамки дозволенности потребителя (в смысле программиста). Т.е. я за код с явной типизацией, порядка больше. Да и в php переодически привожу к типу насильно... В конце концов мне лучше знать какой тип мне необходим.
Но напрягают иногда функции типа Integer.toString() - и не дай бог в регистре ошибешься :) Но это дело привычки и печатается быстро (особенно учитывая всякие "автокомплит" современных сред разработки)


Kerk ©   (22.12.13 23:09[39]


> antonn ©   (22.12.13 23:03) [38]

Так ведь нет глобальной разницы между тестами и типизацией. С помощью типов ты описываешь некие требования к коду, на соответствие которым компилятор будет твой код проверять. С помощью тестов ты точно так же описываешь требования к коду (только более высокоуровневые). И над архитектурой лишний раз подумаешь, и порядка станет больше, и не поломаешь ничего по глупости. В ПХП ты легко можешь в функцию параметр другого типа передать, а узнаешь об этом только когда-нибудь потом. Так же и с тестами. Код может компилироваться, но последние изменения нарушили логику работу. Если этот код был покрыт тестами, то ты скорее всего об этом сразу узнаешь, а не потом.


jack128_   (22.12.13 23:45[40]


> Kerk ©  

Зачем нужна типизация - это не интересно.
Ты лучше опиши, как ты представляешь себе работу именно в DelphiSpec.
Ну вот кто конкретно будет писать эти spec тесты и когда. Можно на примере своей работы если эта штука туда внедрена.

Ежели нет, то представим такой сценарий.
Вот пришел заказчик и сказал: "Ну это.. Типа маза такая есть, тут наши девки из бухгалтерии хотят видеть когда всякие челы в отпуск уходят/приходят. Ну вы там подкрутите что да как."
Вот кто/когда будет писать эти spec'ификации. Можешь описать?


Kerk ©   (23.12.13 00:44[41]

Я наверно так скажу. Если несколько моих попыток и даже ссылка на большую-большую статью не помогли, то оно тебе не нужно. Это нормально.


Пит   (23.12.13 01:14[42]

мне кажется Kerk не понял Jack'а... Точнее, понял, но нежелание расписать именно этот момент, который и является основным для продвижения (таки программирование как прикладная область или программинг ради программинга) - пугает.

Тем более, Женя понимает и даже считает полезным TDD. Поэтому если даже для него все столь неочевидно - у Ромы конкретные пробелы в плане донесения информации ))

Я не понял так вообще нихрена (

Это сугубо имхо, конечно. Не для того, чтобы расстроить Kerk'а, а для того, чтобы дать обратную связь от человека, уровня немного выше среднего и давно работающего с дельфи


antonn ©   (23.12.13 08:50[43]


> Kerk ©   (22.12.13 23:09) [39]

вот я и не понял, тест вместо меня будет генерить основной код который мне потом надо будет отлаживать, или я буду писать свой обычный код и потом еще писать сценарии?
я действительно не вижу причин делать этот over-скриптинг, и думал ты мне на пальцах и своими словами объяснишь, так как статьи на хабре мне никак не объяснили - куча иностранных крутых слов, а конкретики никакой, увидеть бы реальный проект куда оно внедрено, позапускать и сравнить. А то вокруг только теоретические выкладки про "эффективность"


Kerk ©   (23.12.13 12:07[44]

Еще несколько мнений по ссылке.
http://programmers.stackexchange.com/questions/160411/what-is-a-legitimate-reason-to-use-cucumber

Нет, серьезно. Если потребность до сих пор не почувствовалась, значит оно вам не нужно. И это нормально. Мне трудно раскрыть тему шире, чем я уже раскрыл. Я все-таки программист в первую очередь, а не евангелист, например. Если реально есть интерес чуть дальше, чем поболтать на форуме, то в интернете очень много материалов по Gherkin, Cucumber, SpecFlow и т.д. Есть книжка "specification by example" и некоторые другие. Но опять же - совсем не обещаю, что оно вам реально нужно.


Kerk ©   (26.12.13 00:10[45]

Feature: Accounts

Background:
 Given users exist:
   | id | name  | password |
   | 1  | Roman | pass1    |  
   | 2  | Other | pass2    |


Scenario: Correct Login
 Given my name is "Roman"
   And my password is "pass1"
 When I login
 Then I have access to private messages

Scenario: Incorrect Login
 Given my name is "Roman"
   And my password is "pass2"
 When I login
 Then access denied

Scenario: Remove user
 Given my name is "Roman"
   And my password is "pass1"
   But user "Roman" has been removed
 When I login
 Then access denied


Добавил поддержку блока "background". Он позволяет задать контекст выполнения сценариев.


Dennis I. Komarov ©   (26.12.13 09:51[46]

Ром, ты извиняй, но ИМХО достичь обратную связь с помощью скриптов будет очень очень сложно, а время на их написание потратишь ты... Думаю что толк из этого будет, когда "не программисты" будут писать, а не читать... Посмотри спецификацию BPMN ;)


Kerk ©   (26.12.13 12:15[47]

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

Поэтому я и разместился где-то между :)


Dennis I. Komarov ©   (26.12.13 13:38[48]

рисовать проще чем писать...


Inovet ©   (26.12.13 14:35[49]

> [48] Dennis I. Komarov ©   (26.12.13 13:38)
> рисовать проще чем писать...

Это смотря что рисовать и что писать.


Юрий Зотов ©   (26.12.13 16:22[50]

> Kerk ©   (26.12.13 12:15) [47]

"Непрограммисты" бывают разные. Работал и с такими, которые не только бизнес-процессы знают, и не только способны их внятно объяснить, но при случае могут и SQL-запрос написать, и от блок-схем в обморок не падают, и даже код понять способны (пусть без деталей, на макроуровне). Но работал и с такими, которые в режиме off-line хотят получать на клиенте данные, расположенные на другой машине.


Юрий Зотов ©   (26.12.13 16:34[51]

А по сабжу... пока что вижу две полезности: понятный язык описания тестов и автоматическая генерация тест-юнитов. Все хорошо, если придерживаться правила "сначала тест-юниты, затем код". Но практика часто диктует свои реалии - во-первых, большой проект замучаешься покрывать тестами, а во-вторых сильно возрастает время разработки, в то время, как тебе говорят "кончай дедукцию - давай продукцию".


Kerk ©   (26.12.13 19:14[52]


> Юрий Зотов ©   (26.12.13 16:22) [50]
> "Непрограммисты" бывают разные.

Потому и говорю, что "оба правы". Истина, как обычно, где-то посередине :)

> Юрий Зотов ©   (26.12.13 16:34) [51]

Радует наличие взаимопонимания. Я же в общем-то и не говорю, что оно нужно всегда и всем, но кому-то ведь нужно.


Юрий Зотов ©   (26.12.13 23:45[53]

> Kerk ©   (26.12.13 19:14) [52]
> Радует наличие взаимопонимания.


Меня тоже. Пришло время...
;o))))))))


Kerk ©   (27.12.13 09:49[54]

Добавил поддержку задания структуры сценария:

Scenario Outline: Add two numbers
 Given I have entered <num1> in calculator
   And I have entered <num2> in calculator
 When I press Add
 Then the result should be <sum> on the screen
 
 Examples:
   | num1 | num2 | sum |
   |  1   |  2   |  3  |
   |  4   |  5   |  9  |
   |  3   |  1   |  4  |

То есть вместо пачки похожих сценариев, можно задать структуру сценария и табличку с данными. В результате такая структура будет развернута в несколько сценариев - на сколько данных в таблице хватит.

Это уже практически предпоследняя фича из тех, что я хотел в рамках этого проекта реализовать. Релиз DelphiSpec 0.9 не за горами, думаю, пока документации нет нормальной, называть ее 1.0 было бы нечестным.


Kerk ©   (27.12.13 20:58[55]

Я был бы, кстати, очень благодарен, если бы нашлись добровольцы проверить хотя бы компилируемость демо-проекта в версиях Delphi от 2010 и выше. Пока что проверялось только в XE и XE5.


Kerk ©   (28.12.13 10:54[56]

Добавил поддержку "питоновских" "многострочных строк"

Feature: Spam Filter

Scenario: Blacklist
 Given I have a blacklist:
     """
     m@mail.com
     123@mail.com
     """
   And I have empty inbox
 When I receive an email from "m@mail.com"
 Then my inbox is empty


А так же разрешил комментарии после объявления Feature

Feature: Calculator
 In order to avoid silly mistakes
 As a math idiot
 I want to be told the sum of two numbers


Scenario: Add two numbers
 Given I have entered 50 in calculator
   And I have entered 50 in calculator
 When I press Add
 Then the result should be 100 on the screen


Пожалуй, это все, чего я пока от DelphiSpec хочу. Сосредоточусь на тестировании :)


картман ©   (28.12.13 14:45[57]

XE3 компилирует. А что такое DUnitTestRunner? нинашел


Kerk ©   (28.12.13 14:54[58]


> картман ©   (28.12.13 14:45) [57]

Это из DUnit. Оно есть в поставке Delphi, но во время установки ты мог эти галки снять.


Kerk ©   (28.12.13 14:55[59]

А за тест спасибо! Найти бы еще кого-то с D2010.


картман ©   (28.12.13 15:25[60]


> Это из DUnit.

в путях не было.
Было б неплохо при "Run" подгружать данные из поменявшихся файлов feature.


Дмитрий Белькевич   (28.12.13 21:43[61]

Пробую на 2010 собрать. Не могу найти DUnitTestRunner. Я не уверен, что в 2010-м он был. У меня еще есть XE3, то в нем есть.


Дмитрий Белькевич   (28.12.13 21:47[62]

RegularExpressions тоже нет.


Kerk ©   (28.12.13 21:48[63]

Неужто там DUnit в поставке не было? Или модуль иначе назывался? Попробуй, пожалуйста, пустой проект DUnit создать и посмотреть, что там в .dpr


Kerk ©   (28.12.13 21:50[64]

О как. Если регэкспов нет, то беда. Придется считать, что оно работает начиная с Delphi XE.

Спасибо!


Дмитрий Белькевич   (28.12.13 21:58[65]

SplitString нет и еще, видимо того-сего. Так что гляди - стоит ли допиливать или считать как XE+.
Интересно, возможно применил бы где-нибудь, есть мысли. Но уже, наверно, когда на XE5 переползем...


Kerk ©   (29.12.13 22:57[66]

Промежуточный итог
http://roman.yankovsky.me/?p=1355


версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 





Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо