Ясненько, понятненько.
Ну это точно не для инди проектов.

Да на что тут можно обижаться? К сожалению такого опыта нет (а может и ксчастью, хз). У нас команда маленькая.
Но, раз уж разговор пошел о юнит тестах, я просто не мог поверить, что такая известная штука как юнити, страдает их отсутствием. И нагуглил вот это http://blogs.unity3d.com/2014/07/28/...ty-test-tools/
Мне сложно судить на сколько это удобно, так как для меня вообще юнит тесты не удобная штука, но, тем не менее.
В общем, как я понял, у тебя просто предвзятое отношение к юнити из-за каких-то неоправданных ожиданий, возможно. Утверждать, что она подходит для всех игровых проектов - глупо. Конечно же нет. Действительно, есть такие проекты, где проще и лучше запилить что-то свое. Но процентов 85 - 90 она точно может покрыть. И дело ведь не в том, на сколько технически сложнен проект, а в том, какой фан он создает. Часто простые игры затягивают гораздо сильнее, чем навороченные с многомиллионными бюджетами

Это как героин. Стоит один раз увлечься и...
Но вообще говоря, здесь уместней сравнение с ООП при AS2 – сначала непонятно, странно и хочется написать в процедурном стиле (или смешать и то, и то), но после осознания голова не работает иначе. Сейчас перед тем как написать любой код я первым делом думаю, как написать для него разные тесты на разных уровнях. Доходит вплоть до попиксельных сравнений картинок, если манипулирую ими.
В контексте сбора приложений, грубо говоря, она должна быть всегда. Внешний консультант при заходе на проект с целью разгрести кучу мусора первым делом будет делать именно то, чтобы проект запустился с одной кнопки, или, максимум, с строго предетерминированным порядком действий (который, кстати, можно запихнуть в скрипт и вот она, одна кнопка!). Общих решений подходящих везде не существует, но для каждого отдельного проекта сборка в одну кнопку просто essential. Сравни какой-нибудь MEAN Stack и Hadoop в простоте сборке. Они вообще для разного, но со вторым можно умом тронутся пока он просто встанет. (на всякий упомяну, что мой скоуп знаний о Hadoop достаточно старый – надеюсь, многое изменилось).

В целом, так и есть. Писать тесты дешевле и это ускоряет разработку в long-term плане, чем иметь много QA-мартышек, что будут везде искать регрессии.

Речь про абсолютное число? Это флуктирующее значение и тест-тесту рознь. один e2e тест даёт большее покрытие кода, чем 3 unit, но они тестируют разные вещи. Один тест может прогонять несколько ассертов, в то время как этот тест можно разбить на несколько мелких по одному ассерту (понятность того, что тестируем против скорости выполнения тестов).
Самое примитивное - метрика по покрытым линиям кода (LOC), но 100% покрытие гарантирует только что на каждой ветви кода существует сценарий, при котором код не падает. Однако, имея 100% LOC Coverage и контроллируя, что тесты делают то что нужно (и в нужных пропорциях, я бы сказал, что 65% Unit, 25% Integration и 10% e2e – знаю я ковбоев, что тестируют только через e2e, но получают неплохую метрику) можно очень радовать себя простотой разработки и рефактора, и конечного пользователя стабильным приложением.

Что в целом составляет 100% бизнес логики :D

Нет, это для любых проектов.

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

Тесты должны отрабатывать, каждый раз при сборке проекта

О, а вот это что то новое. В дебаговом билде так понимаю? Мысль интересная. Но всё равно я сомневаюсь в целесообразности их полноценной реализаций для небольших проектов, хоть и уже немного меньше. :)

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

А что такое юнит-тест?

Такая секретная технология, что по ней инфы много, но нормального примера нет. И тот, кто ее познал почему то тоже не может внятный пример показать.

Ну, речь изначально шла немного о другом. В юнити нельзя сразу открыть чистый проект и собрать его, скажем, под андроид. Но после парочки нехитрых настроек, все будет делаться именно в нажатие одной кнопки. Там это Ctrl + B или File -> Build & Run. Вот, собственно и все. Так что именно эта пресловутая "одна кнопочка" там есть, но ее надо сначала подключить. А я и написал вопрос "а где она есть?", с целью узнать где может быть такое, чтобы без настроек сразу из коробки работало. Ни разу не встречал.

Юнити можно сбилдить из голых сорсов через command line интерфейс?