Я подумываю уйти в стройку каркасников. Уж больно они мне нравятся, да и работа на свежем воздухе.

каких каркасников?

Вижу, что ты написал ИМХО, поэтому тоже скажу свое имхо. Мне вообще юнит тесты никогда не пригождались. Если делить программистов на тех, кто без юнит тестов жить не может, и тех, кому они вообще не нужны, то я второй вариант. Пробовал как-то раньше в джаве делать все "по фен шую" с юнит тестами, и быстро пришел для себя к выводу, что это бессмысленное занятие. Я не утверждаю, что это на 100% так, может быть реально есть ситуации, где они очень даже полезны, но мне за 7 лет ни разу такой ситуации не встречалось.
Нет. А где такая кнопочка есть? Во флеше уж точно нет. Но после того, как ты все настроишь первый раз, то последующие сборки - это не проблема (так же как и во флеше, собственно)
То есть, ты хочешь сказать, что во флеше это делается на раз два?
Задача вполне решаема, и на флеше и на юнити, но и там и там, она потребует определенных усилий.

Ну и, помимо юнити есть еще Unreal Engine, у которого даже исходники открыты. Отличная технология, но тоже не лишенная своих минусов. Поработав и в том и в том, пришел к выводу, что для ПК анрил лучше, а для мобил - юнити. Все это тоже мое ИМХО.

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

Что насчёт разделения вида от модели в юнити? Я на первый взгляд, как понял, там всё действительно очень высокоуровнево, на столько, что вид от модели не отделим.

На хабре видел статью, где чел делил всех людей по использованию ими тестов. Нет тестов - давай до свидания. :)
пс. Всё хорошо в меру.

как-то так https://www.toptal.com/unity-unity3d...me-development
Да, на хабре много всякой хрени пишут.

Я вижу (без обид) отсутсвие опыта в работе больших команд, где существует текучка кадров и код развивается и мутирует в процессе жизненного цикла продукта. В таких ситуация и unit и integration тесты необходимы (само собой без излишеств), иначе код превращается в полное Г (как показывает практика).
Можно настроить процесс сборки как угодно. Сборка обычно осуществляется с на билд машине, которая подхватывает сорсы из репозитори. Вот (может не самый удачный) пример:
http://www.tiefenauer.info/ci-for-fl...t-0-the-setup/
Например, в Flash используя тот же nape я могу это реализовать и физика будет симулироваться используя одну и ту же библиотеку.
В юнити API встроенной физики мне это не позволяет сделать. Значит мне нужно либо писать свою физику, либо покупать. Но эта физика не будет в любом случае работать 1 в 1 как нативная, и траектория движения шара не будет точной.
И про бильярд это первое, что пришло в голову. А таких вещей во время разработки появляется достаточно. В итоге проще от таких фич отказавться и результат продукта встаёт рядом с остальными наштампованными клонами.

CrazyFlasher,
А можно поинтересоваться, чтоб для сравнения, что это за проект и сколько над ним трудится в один момент времени разработчиков, раз тесты начинают иметь такое жизненно важное значение?

Ну к примеру элементарная кастомная библиотека событий. Да те же as3-signals.
Допустим ты решил написать что-то подобное. Выложил в опен сорс. Другие челы стали тоже юзать, твою клёвую либу. Решил апдейтнуть. Как ты можешь гарантировать, что у других ничего не сломается? Как ты вообде будешь осуществлять тетсирование данного модуля? Обкатывать на своём проекте? - тоже выход. Но неудобно.

Хорошо, понятно.
А вот в рамках большого проекта, сколько примерно приходиться делать тестов?

Ну обычно тестируется всё публичное API моделей. Само собой какие-то тривиальные вещи нет особого резона. Надо осознано подходить.