Автоматизированное тестирование.

[Aquahawk]

В наших проектах есть серверная и клиентская часть.
Команды которые пишут сервер и клиента разные, работают вместе и сидят рядом вместе. Серверсайд адепты TDD, и у них это отлично получается в том числе утечки памяти и прочее. Соответственно баги на сервере находятся крайне редко.

На клиенте у нас творится полный раздрай. Автоматического тестирования нет никакого, всё проверяется тупо ручками. Когда фича сделана она идёт на тест, там её также руками тестят, если что возвращают на доработку. Если мы изменяем функционал какой-то, который затрагивает всю игру, то приходится ретестить многое заново.
Если вы используете TDD, то пользуете ли вы какие-то фреймвёрки или всё сами написали? UI отдельно, или UI и контроллеры вместе. Как вообще вы это дело оцениваете.

В опросе следует читать TDD вместо TTD
iNils: Исправил, заодно добавил пункт "Иногда использую"

[Котяра]

Дело в том, что ТДД легко можно покрыть синхронную логику. Писать тесты для асинхронов - это сложно. Ошибки возникают не во время компиляции и запусков тестов, а при взаимодействии. Во всяком случае нам никак не помогли. Да и писать их муторно. Для того чтобы запустить набор юнит-тестов на сборочном сервере (через тот же Team-city) - нужно делать специальное тестовое окружение - эмулировать действия пользователя, дожидаться загруки (или не загрузки), потом повторять всё по-новой..
Для каких-то простых вещей можно, но в них никто и не ошибается практически.

[mikhailk]

Опытным путем установлено, что бета-тестирование рулит.

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

[Котяра]

Вики со мной согласна.
Как раз, почти все случаи относятся к основным моментам разработки flash приложений. Гуи, интерактивность, ассинхронность, сетевое взаимодействие.
2 + 2 = 4 можно проверить, но обычно такие вещи проверяются легко и без тестов.

[incvizitor]

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

[wvxvw]

Я когда-то писал робота клиента, который бы делал все то же самое, что может сделать обычный пользователь. Из чего почерпнул следующее:
- это дофигища работы. В моем случае, я фактически переписал большую часть веб сервера по-новому для того, чтобы оно заработало, т.как оригинальный веб сервер не подходил по многим параметрам.
- даже на начальных этапах это помогает найти массу упущений на обоих сторонах. Но может оказаться так, что упущений на столько много, и они такие фундаментальные, что исправлять их в обозримом будущем не будут.
Вобщем, до реального использования никогда так и не дошло.
Примеры конфликтных ситуаций:
Нештатное поведение клиента может свалить сервер - нужно что-то придумать, чтобы клиент автоматически мог его перезапустить.
Желательно имитировать работу множества клиентов одновременно - нужна инфраструктура для того, чтобы на одной машине можно было это множество как-то запустить.
На сервере нужно вменяемое логгирование исключительно для тестов, и так же на клиенте. Логгирование из флеша - это цирк тот еще... Флеш вообще не в состоянии быстро логи высылать никуда, ни в трейс ни в сокет, ни через EI.
Я пришел к тому, что писал целый скриптовый язык для того, чтобы описать поведение клиентов-ботов. Я даже где-то выкладывал полу-рабочую версию... кстати, о, надо бы допилить когда-нибудь
Последнее - вобщем-то интересное занятие, но отнимает безумно много времени.

[carrotoff]

Сервер наших продуктов практически на 100% покрыт тестами. И для разработки сервера тесты реально экономят время. Хоть и писать кода приходится больше, но экономия времени очень существенная (в основном она берется за счет отсутствия неявных багов и ошибок, и, соответственно, очень маленького времени на отладку)

Клиентскую часть покрываем тестами только в опасных местах, в основном взаимодействие с сервером и ядро (что называется framework). Вообще, согласен с Котом, клиент очень тяжело тестировать в силу асинхронности, потому чаще это оказывается неоправданным занятием.

А по теме, очень интересно услышать мнение товарища expl. Я когда-то у него интересовался тестами.

[expl]

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

Прикол в том, что тестирование асинхрона в большинстве случаев легко сводится к синхрону (я вообще не пишу асихронные тесты, хотя тестировал кучу клиентских асинхронных вичислений, разворачивающихся во времени)

(Речь про unit-тесты, т.е. про покрытие отдельных проблемных кусков)

P.S. Добавь пункт "Использую в полсилы, отказываться не собираюсь"

[Inet_PC]

Прикол в том, что тестирование асинхрона в большинстве случаев легко сводится к синхрону

Легко это как?

[expl]

Подменяешь таймер или Datе или Loader (или ещё что-то, с чем работает класс под тестом) на заглушку, с помощью которой синхронно имитируешь асинхронную работу. И тест легче читается и работает быстрее и срабатывает всё время одинаково, и точность выше, если от промежутков времени результат должен зависеть.