Крик души о ТДД во вью

[Dukobpa3]

Собственно на сервере использую, нравится. Там по сути только модель и команды, главное проследить чтоб в модель попали нужные данные, и чтоб после обработки они были правильно отформатированы. Всё.

Теперь клиент. Архитектура мвц.
Пишу максимально инкапсулировано. Ну т.е. Я люблю всякие там статик манагеры для доступа к пулу вью, моделей и прочих одноранговых плюшек, но каждый объект выдает наружу только ивенты + парочку или вообще без паблик методов.

Так вот.
Тестируем модель. Ну тут ок. Как сервер. На фход скормили данные, проследили чтоб математика правильная была, всё круто.
Следующим тестом проверяем чтоб по таким-то изменениям были такие то диспатчи. Асинхронные тесты в помощь, но в целом не сложно.

Теперь контроллер.
Всё немного сложнее. В модель мы кормили данные, в контроллер же скамливаем какую-то мок-вью, через нее диспатчим, следим чтоб контроллер как-то реагировал. Усложняется тем что реакция контроллера выражается в вызове паблик метода модели. Т.е. ему нужно мок-вью, которая умеет спамить клики + мок модель, которая умеет слушать коллбеки. Но ладно, разобрались.

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

//**************************************
Короче пыжусь вот я со вьюхами но никак ни к чему не пришел внятному. В хаксе более менее проканывает, потому что там после компиляции все приваты становятся пабликами, так что могу чуть ли не насквозь всё смотреть.

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

//**************************************
Вот и интересно как кто чего в этом плане делает.

[Psycho Tiger]

Я не делаю, но если делал бы - то в ядро архитектуру вшивал бы функционал для интеграционных / е2е.
Не то чтобы круто, но других идей у меня нет.

Поднимал тему о бдд несколько месяцев назад, кстати - wxvxw там рассказывал свои мысли.

[Dukobpa3]

BDD вроде бизнес, а не тех решение? Нет?

в ядро архитектуру вшивал бы

Для е2е согласен, для ТДД как-то не очень. Вроде тесты должны помогать, а не заставлять менять архитектуру (которая зарекомендовала себя на не одном проекте). Я привык к мвц, мне нравится. А тут получается надо совсем уж подходы поменять. Энтити систем какую-то или типа того? Ну каждую энтити проще будет протестить, это да. Только как-то неохота вот так вот брать и всё менять.

[Psycho Tiger]

Ну, я понимаю разницу примерно так, как описано здесь здесь. Мне нравится BDD тем, что он читабельней и "портируемей". Ну, то есть, сравни rspec (руби/рельсы тест фреймворк), капибару (тоже руби/рельсовое, но уже с клиент-сайдом в лице браузера) и жасмин (чисто клиентское). Умеешь "читать" один из этих фреймворков – сможешь прочитать любой другой. Но по сути, разницы нет. TDD только говорит о том, что сначала тест – потом код, а BDD говорит ещё и как этот тест писать. Ну, это моё виденье =)

Для е2е согласен, для ТДД как-то не очень.

Ну так и e2e тоже может быть ТДД, это вещи не взаимосвязанные. Можно написать код, а потом покрыть его тестами, а можно сначала написать тест, а потом озеленять его. Просто ТДД чаще применяют к юнит-тестам.

Честно, я бы на твоём месте особо не заморачивался – если ты пишешь юнит тесты, это уже хорошо (вроде, Flex::Unit для этого есть?). Замечательно, если покрытие ещё побольше, чем 30% и просто супер если действительно есть хотя бы немного е2е. Я всё таки сторонник, что тесты должны отнимать не больше времени, чем непосредственно сам код.

Что касается самих подходов – в моей голове всё проще; Действия пользователь чаще всего скатываются до "кликни здесь, нажми букву, кликни сюда" – и тест я вижу записанные так же. Что-то вроде

find('main', 'inventoryButton').click.expect('window', 'inventory', 'open').find('inventory', 'potion').click;
player.hp.should.equal(100);

А между действиями по типу click и expect взводить таймер на 1 мс. Это вынесет всю обработку уже в следующий фрейм – нужно же время, чтобы инвентарю открыться.

[Dukobpa3]

e2e это ж типа тестирование внешней тулзой в основном.
Но архитектура должна позволять распарсить ДОМ.

Т.е. Запускаем тестирование и пошли курить. А тулза там кликает по кнопкам и проверяет функционал с точки зрения пользователя. (для этого и распарсить ДОМ, чтобы можно было диспатчить клики от имени кнопки)

Или я че-то не то рассказываю?

[Psycho Tiger]

Egde 2 edge это интеграционный тест – просто название другое. Кто-то говорит, что есть различия – но даже если и есть, то они весьма надуманные, имхо.
Суть тут такая, что это тестирование всего скопом. Комплексная работа всего приложения – от вьюх до контроллеров. В MVC логично ограничиваются тем, что подёргали вью – посмотрели модель. Если всё окей, то и контроллер окей – традиционно его считают "клеем" между вью и моделью.
Я это всё к чему: если тестировать браузером – то всё более-менее просто: есть DOM, он один для всех сайтов и либу для тестирования можно выложить отдельно (capybara, например). С флешем всё чуть сложнее, но по сути дисплай лист то же самое дерево; Другими словами, можно нагородить механизмов рефлексии для получения любого элемента. Что касается моделей – опять же, на бэкэнде это БД и изменения можно посмотреть там почти "напрямую", для флеша опять же придется городить свою систему.
В конечном счете, я смирился с тем что если я хочу такое тестирование – мне придется почти полностью переписывать механизм под каждый конкретный проект. В целом, решение спорное, но если проекту действительно требуется серьезное тестирование – то это хоть что-то.

По поводу внешней тулзы – всегда, конечно, приятней если логика тестирования будет отделена от логики самого приложения. Но конкретно в случае флеша я бы не сильно расстроился, если бы эти тесты полностью доставлялись клиенту. У чувака что-то глючит (а такое может быть из за багов / разных версий флешплеера), подсказали ему комбинацию клавиш и смотрим, все ли тесты прошли.

P.S. Только сейчас подумал, что, вероятно, ты DOM употреблял не в контексте браузеров, а в контексте дисплай листа; Если да – то да, ты меня понял верно.

[Dukobpa3]

DOM употреблял не в контексте браузеров, а в контексте дисплай листа

Именно это и имел в виду.