А мне нравиться, всегда мечтал чтобы у моего шаффла зарядка механическая была. Ктому же «карандашная зарядка» наверно как дополнение к зарадке через usb.
Что то вы сильно боитесь конкуренции, не уверены в своем преимуществе?:)
Для конечного пользователя же важно качество ресурса, а оно достигается в конкурентной гонке.
Так что конкурентная борьба по-моему самое то.
Понял причину нашего спора:) Вы смотрите на TDD/BDD более широко, с точки зрения общего цикла разработки ПО. Эта же статья и сам фреймворк RSpec нацелены на BDD только в контексте написания кода.
Для менеджера BDD одно, для программиста другое:)
Статья не моя:) Лично я считаю что функциональное тестирование и BDD — это разные вещи.
Еще нужно добавить, для точности, что вообще то юнит тестирование не тоже самое что и TDD.
Юнит тестирование — это метод тестирования, а TDD — это подход к разработке кода, основанный на юнит тестировании.
Точно также и с BDD. В общем случае можно сказать что тестирование поведения это и есть функциональное тестирование, когда тестируется черный ящик. Но BDD — это подход к написанию кода, используя тесты поведения по спецификации. Что нам и демонстрирует фреймворк RSpec.
«Более того, TDD не обязательно следует применять для проверки равенства. Применяйте методику для тестирования логики по спецификациям.»
Вот так и появилось BDD:) И это уже более высокий уровень чем assertEquals и т.п.
«В данном ключе BDD — это тот же TDD, просто чуть более высокоуровневый.»
По сути, так и есть, я и написал выше что его можно рассматривать как слой абстрации над TDD.
А то что касаеться FIT, вы просто путаете функциональные тесты с BDD. Функциональное тестирование, которое может проводить не только программист но и тестер и пользователь, прежде всего подразумавает «черный ящик», т.е. тестирующий не имеет представления как это работает, и тестирует некие функиональные куски и их интеграцию. В BDD пользователь конечно может прогнать тесты, но вот написать — врядли.
«Основная цель: привлечение к тестированию пользователей продукта, где они могут создавать тесты на бизнес-языке и проверять работу приложения в автоматическом режиме. Насколько я понял из Вашего примера — это есть одно и то же.»
Нет, в BDD тесты пишет сам программист, так же как и в TDD. А то что синтаксис библиотеки RSpec выглядит как BNL — это синтаксический сахар Ruby.
И все-таки BDD и TDD соперники, нет смысла писать юнит тесты если есть спецификации. BDD можно рассматривать как новый слой абстракции над юнит тестами. Если там мы просто проверяем равенства и т.п., то тут проверяем соответствия поведения реальной функции/объекта с поведением описанным в спецификации, правда используя теже методики:)(всмысле проверка на равенство и т.д.)
"… музыкального продукта, который находится в ограниченной продаже на территории России, либо отсутствует в открытой продаже..."
Я сильно подсевший на психоделику и гараж 60х, надеюсь там что-нибудь интересненькое найдеться:)
Заодно своей коллекцией поделиться могу.
def check str
stack = []
str.split(//).each do |c|
if '{[('.include? c
stack.push c
else
return false if c != stack.pop.tr('{[(','}])')
end
end
true
end
puts check('[[[]]][][[]][()]{}[]') #=> true
puts check('[[[)]]][][[]][()]{}[]') #=> false
Для конечного пользователя же важно качество ресурса, а оно достигается в конкурентной гонке.
Так что конкурентная борьба по-моему самое то.
Для менеджера BDD одно, для программиста другое:)
Еще нужно добавить, для точности, что вообще то юнит тестирование не тоже самое что и TDD.
Юнит тестирование — это метод тестирования, а TDD — это подход к разработке кода, основанный на юнит тестировании.
Точно также и с BDD. В общем случае можно сказать что тестирование поведения это и есть функциональное тестирование, когда тестируется черный ящик. Но BDD — это подход к написанию кода, используя тесты поведения по спецификации. Что нам и демонстрирует фреймворк RSpec.
Вот так и появилось BDD:) И это уже более высокий уровень чем assertEquals и т.п.
«В данном ключе BDD — это тот же TDD, просто чуть более высокоуровневый.»
По сути, так и есть, я и написал выше что его можно рассматривать как слой абстрации над TDD.
А то что касаеться FIT, вы просто путаете функциональные тесты с BDD. Функциональное тестирование, которое может проводить не только программист но и тестер и пользователь, прежде всего подразумавает «черный ящик», т.е. тестирующий не имеет представления как это работает, и тестирует некие функиональные куски и их интеграцию. В BDD пользователь конечно может прогнать тесты, но вот написать — врядли.
Нет, в BDD тесты пишет сам программист, так же как и в TDD. А то что синтаксис библиотеки RSpec выглядит как BNL — это синтаксический сахар Ruby.
И все-таки BDD и TDD соперники, нет смысла писать юнит тесты если есть спецификации. BDD можно рассматривать как новый слой абстракции над юнит тестами. Если там мы просто проверяем равенства и т.п., то тут проверяем соответствия поведения реальной функции/объекта с поведением описанным в спецификации, правда используя теже методики:)(всмысле проверка на равенство и т.д.)
Я сильно подсевший на психоделику и гараж 60х, надеюсь там что-нибудь интересненькое найдеться:)
Заодно своей коллекцией поделиться могу.
Решение в две строчки:
def check str str.gsub!(/(\[\]|\(\)|\{\})/, '') while str =~ /(\[\]|\(\)|\{\})/ str == '' end puts check('[[[]]][][[]][()]{}[]') #=> true puts check('[[[)]]][][[]][()]{}[]') #=> falsedef check str stack = [] str.split(//).each do |c| if '{[('.include? c stack.push c else return false if c != stack.pop.tr('{[(','}])') end end true end puts check('[[[]]][][[]][()]{}[]') #=> true puts check('[[[)]]][][[]][()]{}[]') #=> false