Системное тестирование игры

[expl]

Доброго времени суток всем!
Имеется типичная проблема:
- есть более-мене простая социалка as3-клиент/php-сервер
- сыт по горло мышкокликаньем при воспроизведении сложных багов в клиенте и сервере(ведь если бага на сервере, то в 50% случаев это ещё нужно доказать, а значит, воспроизводить тебе, а не серверисту)
Тут же как:
Прогнал цепочку из 50 действий. Ура, бага нашлась! Вроде зачинил, надо проверить - и опять 50 дейсвий. А если только думал, что зачинил - повторяешь на бис

Да, большинство сложных алгоритмов покрыто unit-тестами (только благодаря ним мы не сидим с дебагером в разборе ответов сервера, и с помощью них удавалось вылавливать баги, воспроизводимые в десяток шагов).
Но это unit-тесты и строчить их для компонент, завязанных на многие другие толку нет - только время убивать и дополнительные зависимости в проект вносить.

Нужно системное тестирование, например такой тест:
- сбросить игру
- юзер открыл окно "Инвентарь"
- юзер выбрал морковку
- проверить "произошёл переход в режим посадки"
- юзер посадил морковку
- проверить "юзеру дали выполнение квеста quest1_2_3"
- проверить "юзеру показали окно с наградой"
По крайней мере, спасение видится в этом.

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

[Psycho Tiger]

У нас есть седеющий тестер.
Мне кажется, что везде такой должен быть - это очень проблемно делать такое автоматическое тестирование.

[expl]

Это идея, конечно, хорошая
Приходилось работать с тестерами - классное было время: набрушил - вроде должно запускаться - а прогоним ка мы через тестера, а сами ещё чего поделаем - о, тестер нашёл багу и объяснил как она появляется - чиним - сказка!
А ещё тестеры умеют обяснять как оно "должно работать", если ты забыл.
Но:
- мы не можем сейчас позволить себе тестера;
- тестер все-таки выдает результат с куда большей задержкой, чем автоматический тест. И он загружен не только твоей задачей.

[Psycho Tiger]

Ну блин, какой ответ ты хотел услышать? Такие штуки очень завязаны на архитектуре приложения.
Кликнуть здесь-там-сюда - есть класс, по-моему, у wxvxw, имитирующий клик (рассылка пачки MouseEvent через getObjectsUnderPoint). Осталось только ждать разблокировки экрана в асинхронных местах.

Или нужен какой-то механизм адекватного композита вьюх. У меня у главной вью были методы getView(type:Class) - возвращали нужную вью, вне положения иерархии, оттуда я получал ссылки на нужные мне элементы или вообще рассылал события от их имени, вроде

getView(InventoryView).dispatchEvent(new ItemEvent(ItemEvent.SELECT, 3));

Это всё дело можно завернуть в некоторый конвеер, давая ему указания, мол, сгенерировать событие, подождать ответ от сервера с заголовом "item select ok" - получится достаточно читабельно.

Но опять же, такое тестирование завязано на архитектуре. Не видя как устроено твоё приложение давать адекватные советы - очень странное занятие.

[expl]

Хотябы такой ответ получить и рассчитывал.

Но опять же, такое тестирование завязано на архитектуре. Не видя как устроено твоё приложение давать адекватные советы - очень странное занятие.

Если есть описание автоматического тестирования в твоей личной архитектуре - это уже хорошо.

getView(TypeOfView), кстати, выглядит многобещающе - не ошибешся с типом объекта и интерфейс получения - один метод на всё про всё. Для чего использовал, если не секрет?

[Psycho Tiger]

У меня была странная система, в которой можно было получать всё, что присоединено в этот момент.
Контроллеры нарастали горизонтально, то есть любой контроллер мог добавить другой контроллер, и оба этих контроллера были равноправными. Но чтобы общаться между ними - приходилось как-то получать на них ссылку. Для этого и были придуманы getController(type:Class). Аналогично, левому контроллеру иногда нужно было получить ссылку на левое вью - зачем - не вспомню, и эти методы были добавлены именно для этого. Но конкретный профит я получил, когда вдруг нужно было сделать туториал - щелкай здесь, тут, здесь.
В неком TutorialController я говорил вьюхам в разных частях приложения подсвечивать нужные элементы и блокировать те, куда в туториале жать не надо да и вообще, получал любую информацию и пользовательских действиях. Вышло достаточно удобно.

[expl]

Ничего себе...
Звучит дико, ведь глобальная доступность до добра не доводит. Но для тестового сценария всё-таки попробую.
А как ссылки на вьюшки заносил?
Всмысле вьюшки сами себя добавляли и удаляли из коллекции, или главная вюшка у себя в детях копалась и рекурсивно их по типу разыскивала при каждом вызове getView()?

[wvxvw]

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

Пример:

private function clickHandler(event:MouseEvent):void
{
	this._console.run("(answer " + 
		this._fields.indexOf(event.currentTarget) + ")"); 
}

this._console - это экземпляр класса консоли, что он делает: выводит (или просто записывает) текст программы (или результат работы, закомментированый) и вызывает интерпретратор.
Т.е. код выше вызывает функцию:

public function answer(index:int):void
{
	var type:String = 
		this._winner == index ? 
		ChallengeEvent.WIN : ChallengeEvent.LOOSE;
	super.dispatchEvent(new ChallengeEvent(type));
}

А класс, который слушает события делает что-то типа:

private function looseHandler(event:ChallengeEvent):void
{
	this._console.print("; You loose!");
}
 
private function winHandler(event:ChallengeEvent):void
{
	this._console.print("; You win!");
}

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

Я пока это сделал в очень общих чертах и язык очень-очень мало что умеет. Так только математику + логические операции + какие-то пару утилит.

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

Ближе к вечеру (или завтра), выложу сырцы куда-нибудь. Но они еще в таком состоянии, что людям лучше не показывать



О, вот так на тестах выглядит: клик на одном из выражений - и обрабатываем результат.

[Psycho Tiger]

Нет, вьюшки добавляются контроллером через super.addView(). Всего было 3 типа вьюшек - GUI, которые всегда на экране — они, собственно, доступны через геттеры от главного вью, вьюшки экрана и вьюшки окон (они блокируют экран). Композитных вьюшек не было, только Главное вью -> Вью. Внутри вью могли быть свои вложенности (Display List, всё же), но это уже остается на откуп им.

Звучит дико, ведь глобальная доступность до добра не доводит.

Только для контроллеров. Повторюсь, у меня все контроллеры были равноправны и одинаково главны и выше них никого не было - поэтому вот эта глобальная доступность только для самых высших объектов. Остальное - как у людей )

[PainKiller]

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