Ну, я понимаю разницу примерно так, как описано здесь
здесь. Мне нравится BDD тем, что он читабельней и "портируемей". Ну, то есть, сравни rspec (руби/рельсы тест фреймворк), капибару (тоже руби/рельсовое, но уже с клиент-сайдом в лице браузера) и жасмин (чисто клиентское). Умеешь "читать" один из этих фреймворков – сможешь прочитать любой другой. Но по сути, разницы нет. TDD только говорит о том, что сначала тест – потом код, а BDD говорит ещё и как этот тест писать. Ну, это моё виденье =)
Цитата:
|
Для е2е согласен, для ТДД как-то не очень.
|
Ну так и e2e тоже может быть ТДД, это вещи не взаимосвязанные. Можно написать код, а потом покрыть его тестами, а можно сначала написать тест, а потом озеленять его. Просто ТДД чаще применяют к юнит-тестам.
Честно, я бы на твоём месте особо не заморачивался – если ты пишешь юнит тесты, это уже хорошо (вроде, Flex::Unit для этого есть?). Замечательно, если покрытие ещё побольше, чем 30% и просто супер если действительно есть хотя бы немного е2е. Я всё таки сторонник, что тесты должны отнимать
не больше времени, чем непосредственно сам код.
Что касается самих подходов – в моей голове всё проще; Действия пользователь чаще всего скатываются до "кликни здесь, нажми букву, кликни сюда" – и тест я вижу записанные так же. Что-то вроде
Код AS3:
find('main', 'inventoryButton').click.expect('window', 'inventory', 'open').find('inventory', 'potion').click;
player.hp.should.equal(100);
А между действиями по типу click и expect взводить таймер на 1 мс. Это вынесет всю обработку уже в следующий фрейм – нужно же время, чтобы инвентарю открыться.