Кто бросил программирование ?

[Tails]

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

[caseyryan]

Я вижу (без обид) отсутсвие опыта в работе больших команд

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

[Psycho Tiger]

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

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

Нет. А где такая кнопочка есть?

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

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

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

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

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

Ну обычно тестируется всё публичное API моделей.

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

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

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

[Tails]

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

[CrazyFlasher]

которые отработают один раз и будут лежать мёртвым грузом.

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

[Tails]

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

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

[dark256]

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

[GBee]

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

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

[Zebestov]

Сообщение от GBee

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

Ххаха! Точняк =)

[wvxvw]

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

Например, не далее чем вчера, обнаружил, что на бумаге заявлено что NFS подключений к нашему серверу может быть одновременно 1000, но на практике оказалось, что не больше 200. Я пишу код NFS клиента. Поговорил с программистами, которые делают сервер - они исправили ошибку, но правки пошли в мастер ветку. Кроме мастера, есть релизные ветки, куда это изменение не пойдет, но их все еще нужно тестировать. Код, который я пишу - заказчику не отправляется, он только для внутреннего использования. Мне нет смысла писать две версии клиента - одну с учетом ошибки сервера, а другую - без. Соответственно, я просто пишу версию, которая рассчитывает на 1000 подключений и оформляю баг-репорт для серверной команды.

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

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