Степы обычно очень маленькие, что позволяет их комбинировать и уменьшает необходимость изменения существующих степов и спек. Если чего-то не хватает, гораздо проще дописать еще один степ для этого частного случая. Передавать объекты напрямую, конечно, не получится, но можно, например, сделать builder, которые описывается степами (например, мы так формируем сложный запрос к REST service, а ля «Когда запрашиваем данные с url и когда используем такую-то авторизацию и когда используем такие-то праметры»). Еще можно через DI c помощью степов построить нужный контейнер и дальше вытягивать объекты через него.
Мы используем NBehave в связке с NUnit. Получается что-то вроде такого (точный код на работе):
Код
[TestFixture]
class SomeTests{
[Test]
public void Test(){
@"Given initial value is 5
When multiply it by 2
Then it should be 10
".Execute(In.Context<MultiplySteps>())
}
}
[ActionSteps]
public class MultiplySteps{
int _value;
[Given("initial value is $value")]
public GivenInitialValue(int value){
_value = value;
}
[When("multiply it by $mul")]
public GivenInitialValue(int mul){
_value = _value*mul;
}
[Then("it should be $expected")]
public GivenInitialValue(int expected){
Assert.IsTrue(_value==expected)
}
}
Естественно, степов очень много. Вполне удобно писать интеграционные и функциональные тесты, но unit тесты писать кодом удобнее во много раз. Плюс слишком сложно искать соответствия между степами и реальным кодом (для отладки, например), даже есть самописный плагин для студии, который пытается помогать.
К сожалению, js «хуже» чем асм тем, что слишком высокоуровневый. Для асма пришлось придумывать отладочный символы, дизассемблеры и прочий стафф, позволяющий забыть, что под капотом шевелится, по сути, байткод. ScriptMap — первая ласточка, typescript — вторая. Однако, имхо, глупо терять время на трансляцию кода с одного высокоуровнего языка на другой, чтобы потом терять еще время на его интерпретацию.
JS используют как бейсик, потому то ему нет альтернативы. Только поэтому вокруг него такой ажиотаж и т.п. JS, по сути, ассемблер для браузеров — менно поэтому такая большая куча трансляторов и т.п. — сообщество пытается выйти из узких рамок джаваскрипта. Гораздо круче было бы, если асмом для браузеров стал бы какой-нить байткод, чтобы писать можно было на чем угодно, а не только на JS.
Для выполнения этого кода необходимо, что бы существовал метод Select либо в самом a, либо как extension метод для a. Тоже самое для джойнов, групп и так далее. А используя SelectMany можно комбинировать вызовы — from x in a from y in b select new {x,y}
Небольшой коммент, почему формула работает. Достаточно убедиться, что любой ход не меняет четность N. Следовательно, играя по правилам, нельзя перевести «четную» позицию в «нечетную». У правильной позиции (где все костяшки идут строго по номерам) N будет четным, а у непавильной (где, например, 14 и 15 переставлены) — нечетной.
«Неформальный лидер», который раз в неделю ходит с другими «неформальными лидерами» на закрытое совещание. :)
Писатель у нас один, продукт оунер тоже. Тестировщики и дизайнеры компетентны и достаточно автономны. «Группа» тут скорее не как единица ответственности, а просто те люди, которые будут делать фичу. Но работа по фичам ведь никогда не идет — работа идет по юзерстори, а там больше двух человек вряд ли бывает.
Наше руководство присутствует на отдых силы 70% всех митингов, так что про контроль говорить не приходится. Про придумать — достаточно часто бывает, что на митинге говорят «я не знаю, что сегодня делать» — какой индикатор, что работа закончена.
Час на обсуждение того, чтобы было сделано, имхо, слишком много — вот здесь как раз и можно заскучать.
Ну, во-первых, не 40, а 15 — маркетинг раз в месяц рассказывает о новых клиентах, у ui team свой митинг. Насчет «прервали» не могу сказать — никогда не было в тягость сходить на митинг. А вот про полезность — это спорно, да. Мне, например, полезно — знать, что делается в команде целиком, подсказать, если знаю решение проблемы, попросить помощи, если нуждаюсь. Для других — это надо их спрашивать.
Стандартный stand up — услышать, что делают другие, рассказать, что делаешь сам. Так же услышать от саппорта, какие у них проблемы. Если надо что-то обсудить — это обсуждается после митинга.
Нет, насколько знаю, watin не пробовали. Сейчас мы вообще уходим от функциональных тестов как таковых — UI разделился на rest + JS, каждый тим пишет свои тесты — js на qunit, rest — на питоне, тестирование в браузере как таковое становится не нужным.
Этот коммент хуже никакого и даже хуже пустого. Он явно генерен и сразу же подрывает доверие к остальным коментам в коде. Следуя Роберту Мартину, код должен быть самодокументируемый, что, в принципе, выполняется в примере выше — Exceute выполняет действие, Context — контекст и так далее. Такому коду коменты не нужны. Такое требование законно для авторов фреймворков и тулкитов — но даже там они не должны превращаться во что-то «для галочки». Это очень похоже на требование полного покрытия тестами кода — легко написать тест, который будет полностью покрывать код, но не будет иметь ни одного ассерта — а, значит, будет бесполезен, и даже вреден.
В качестве живого примера можно посмотреть на наши плагины, они доступны на гитхабе: github.com/TargetProcess/Target-Process-Plugins/blob/master/Plugins/Tp.PopEmail/Tp.PopEmail.Tests/BusinessScenarios/HandleEmailsFromUserFeature/WhenMailFromUserReceivedSpecs.cs
Естественно, степов очень много. Вполне удобно писать интеграционные и функциональные тесты, но unit тесты писать кодом удобнее во много раз. Плюс слишком сложно искать соответствия между степами и реальным кодом (для отладки, например), даже есть самописный плагин для студии, который пытается помогать.
Для выполнения этого кода необходимо, что бы существовал метод Select либо в самом a, либо как extension метод для a. Тоже самое для джойнов, групп и так далее. А используя SelectMany можно комбинировать вызовы — from x in a from y in b select new {x,y}
Писатель у нас один, продукт оунер тоже. Тестировщики и дизайнеры компетентны и достаточно автономны. «Группа» тут скорее не как единица ответственности, а просто те люди, которые будут делать фичу. Но работа по фичам ведь никогда не идет — работа идет по юзерстори, а там больше двух человек вряд ли бывает.
* на 70% всех митингов.
Час на обсуждение того, чтобы было сделано, имхо, слишком много — вот здесь как раз и можно заскучать.