Нужны советы по разработке игр

Здравствуйте,Я давно мечтаю создавать свои онлайн игры, Сейчас освоил базу си, покопавшись в нем понял что игр хороших на нем не слепишь, ни один день скитаюсь по форумам, читаю статьи и Решил. Начну изучать C++. Я знаю что разработка игр это нелегко и мне много чего нужно узнать, Я не знаю с чего начать. Сейчас любой совет на вес золота.
А больше мне нравится кодить и придумывать сценарий. Для моих будущих игр я уже придумал частичто свою историю.
Может это и покажется странным, но когда я смотрю прохождение игр, у меня включается во мне разработчик, и я начинаю думать с точки зрения разработчика. Как какая то механика могла быть реализована в коде.

Вобщем Буду очень благодарен вашим Любым полезным советам!

0

Сообщение от Azazel-San И я хочу тестировать именно эту логику.

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

0

Сообщение от Fulcrum_013 В результате получается что нужно покрывать тестами сами тесты

Зачем? Есть конкретные требование к поведению функции которые должны соблюдатся, их задает например заказчик и если что их можно уточнить и все, их в тесте и покрываем, не нужно тестировать абсолютно все что может случится, а только то что ожидаем.

Сообщение от Fulcrum_013 А соответсвенно одно из двух - либо этой функция вообще в коде не используется

Ну вот это может заставить задуматся и удалить ее)

0

Сообщение от Azazel-San Ну вот это может заставить задуматся и удалить ее)

У линкера голова большая пусть он об этом и думает.

Добавлено через 2 минуты

Сообщение от Azazel-San Есть конкретные требование к поведению функции которые должны соблюдатся, их задает например заказчик

Он вообще о функциях знать не должен. Его дело формулировка чаво он хочет от софтины и максимум ТЗ. А исследование предметной области задачи, постановка задачи на основе формулировки и тз, и тем более декомпозиция на функции - вообще не заказчика область компетенции, а разраба и никого более

Добавлено через 6 минут

Сообщение от Azazel-San не нужно тестировать абсолютно все что может случится, а только то что ожидаем.

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

0

Fulcrum_013, ну, не конкретно функции конечно, а например нового функционала, у меня на проекте примерно так и происходит. А что тестирование и декомпозицию нельзя совместить?

0

Сообщение от Azazel-San А что тестирование и декомпозицию нельзя совместить?

А смысл какой? то что if(a==b) сработало тестировать к примеру? так и писанины больше и как результат точек потенциальных ошибок.

Добавлено через 6 минут

Сообщение от Azazel-San а например нового функционала

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

Добавлено через 9 минут

Сообщение от Azazel-San А что тестирование и декомпозицию нельзя совместить?

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

0

Сообщение от Fulcrum_013 А при чем тут IDE к возможности написания на языке эффективных либ для него же самого?

Например, тем, что она написана на Python? А по Mercurial вопросов нет?
Это примеры двух программ на Python, которые я использую. Что характерно, они совсем не тормозят.

Сообщение от Fulcrum_013 Тем что дает возможность на автомате обнулить все ссылки на удаляемый объект. В языках с GC это придется делать исключительно в ручную. Причем в современных иерархиях данных которые используют паттеры композит и обсервер GC без этого удалить вообще ничего не сможет потому что мусором не посчитает.

Как я понимаю, Вы хотите соединить возможность подписываться на события и вызывать метод "Destroy" у объекта, с автоматической отпиской от всех событий?
Приходилось такое писать для десктопного приложения на C#.

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

Предметная область почти всегда меняется. Пресловутые "требования заказчика". А в геймдеве вообще есть специальная профессия, суть которой в том, чтобы менять предметную область. Геймдизайнер называется.

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

0

Сообщение от New man Вы хотите соединить возможность подписываться на события и вызывать метод "Destroy" у объекта, с автоматической отпиской от всех событий

Не только события. Вообще все указатели. Причем без ручного вызова и написания оного Destroy. Т.е. путем однократного создания абстрактного механизма который все это делает сам.

Добавлено через 52 секунды

Сообщение от New man А в геймдеве вообще есть специальная профессия, суть которой в том, чтобы менять предметную область. Геймдизайнер называется.

Нифига он не меняет. А особенно такого что требовало бы изменения кода. Максимум что он меняет - задание для тех или иных элементов.

Добавлено через 1 минуту

Сообщение от New man Unit-тесты именно для того и существуют, чтобы автоматически проверить, что при изменении программы у нас не сломалось старое поведение.

А уже отлаженные компоненты изменять то на кой ляд?

Добавлено через 3 минуты

Сообщение от New man Что характерно, они совсем не тормозят.

Ну у них как бе и лимитов времени на то или иное действие нет в отличии от игры которая должна гарантированно в бюджет кадра укладываться. А тут восприятие тормозит/не тормозит как в иде вообще не показатель. Между двумя кликами дабл-клика аккурат 3 кадра на 60FPS укладываются.

Добавлено через 6 минут

Сообщение от New man Например, тем, что она написана на Python?

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

0

Сообщение от Fulcrum_013 универсального алгоритма блендинга с альфа-отсечением

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

Сообщение от Fulcrum_013 И каким образом это может повысить надежность?

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

Сообщение от Fulcrum_013 А смысл какой? то что if(a==b) сработало тестировать к примеру? так и писанины больше и как результат точек потенциальных ошибок.

Вот что я имел ввиду, допустим нужно добавить функционал ввиде проверки пересечения, сначала я могу написать простенькиий тест в котором опишу поведение которое ожидаю от своего кода, например, пишу тест в духе у меня будет какая-то ф-я bounds_intersect которая будет возвращать true если две границы пересекаются, хотя еще никакой bounds_intersect не существует, тест упадет и только потом я напишу эту функцию и пойму что она слишком сложная и можно усложнить структуру, но на самом деле упростив ее, начнем с простого, сделаем функцию intervals_intersect, которая вернет true если [a0, a1] пересекается с [b0, b1] и напишу для нее юнит-тест с разными интервалами, протестирую когда они пересекаются, когда касаются и т.д.
Потом вернусь к bounds_intersect, которая пусть возращает true если обе проверки пересечений интервалов по х и y возвращают true. Соответственно опишу тесты в таком же духе как и для intervals_intersect. Вот по сути и все, что я имею? Готовый функционал, мог ли я его написать без юнит-тестов? Да, мог. Так чем же они помогли? Ну мне они позволили посмотреть на код возможно под другим углом, тк я его писал в отрыве от всего продакшн кода и сразу же имел возможность протестировать его, посмотреть делает ли он действительно то что Я как программист ожидаю. Вот и все. Да он не протестирован на случай "ядерной войны", и нет гарантий что при каких-то там невероятных условия он будет работать корректно, но мне это и не надо, я пишу поведение чего-то нового зная как оно будет работать, и что если я принимаю целые числа их я и буду принимать в моей реализации никто ничего другого не передаст, соответсвенно я не хочу это тестировать, это глупо покрывать тестами то что с вероятностю 99,9 не произойдет никогда, иначе все верно можно писать тесты и тесты на тесты и никогда не дойти до написания кода. Ну и стоит помнить что мы пишем бизнес приложения где нас постоянно подтарапливают.

Сообщение от Fulcrum_013 НУ это уже больше к интегральному тестированию относится.

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

Сообщение от Fulcrum_013 дебаг-выводом

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

зы - в остальном я понимаю ваш посыл и даже соглашусь почти со всем вами сказанным, но тем не менее тестирование есть и процветает, его многие используют (это не значит же что они тупые), возможно просто к юнит-тестам сейчас стоит присмотрется с другой стороны? Как стиль написания кода?
зыы - «Тестирование не позволяет обнаружить такие ошибки, как создание не того приложения» — Стив Макконелл

0

Сообщение от Azazel-San но тем не менее тестирование есть и процветает,

Это как бы не вина программеров а невежества в этом вопросе менеджеров. А реально процветают грязные трюки по имитация тестирования.

Добавлено через 4 минуты

Сообщение от Azazel-San Вот что я имел ввиду, допустим нужно добавить функционал ввиде проверки пересечения, сначала я могу написать простенькиий тест в котором опишу поведение которое ожидаю от своего кода, например, пишу тест в духе у меня будет какая-то ф-я bounds_intersect которая будет возвращать true если две границы пересекаются,

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

Добавлено через 9 минут

Сообщение от Azazel-San но всегда бог сделает все более тупого пользователя

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

Сообщение от Azazel-San это не значит что логи вести не стоит

Вопрос не в логах. Вопрос в выводе облегчающем отладку. К примеру в вопросе пересечения сразу сделал дебаг-энвайронмент отрисовывающий проекции которые считаются. Сразу видно что именно считает в каком случае и насколько правильно. В результате отладка для полного набора для 2D примитивов на случай ядерной войны заняла не более 2 часов.
Касательно к примеру отладки контейнеров там вывод делался вообще из каждой операции вкключая добавление каждого элемента реаллок и т.п. И его задача визуализировать данные которые трудно воспринять при трассировке.

0

Сообщение от Fulcrum_013 Лучшего способа создать себе кучу проблем не придумать.

Почему? А какие проблемы должны появится?

Сообщение от Fulcrum_013 Реально нужно именно пересечение сделать в универсальном виде

Ну, а если это не нужно, вот есть решение и оно будет работать только в таком ключе и больше никак. Зачем стремится тогда к "универсальности"? Универсальность всегда идет немного в разные стороны с производительностью (опять же не стоит это воспринимать в ключе ко всему, всегда есть исключения). Тем более достичь абсолютной универсальности иногда просто невозможно.

Сообщение от Fulcrum_013 Такой подход плюсом ко всему еще и необходимость рефакторинга исключает напрочь.

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

0

Сообщение от Azazel-San А какие проблемы должны появится?

К примеру несрастуха предпологаемого интерфеса системы определения коллизий и того который будет в результате.

Добавлено через 3 минуты

Сообщение от Azazel-San Невозможно писать идеальный код всегда и везде,

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

0

Сообщение от Fulcrum_013 К примеру в вопросе пересечения сразу сделал дебаг-энвайронмент отрисовывающий проекции которые считаются.

Так это все будет, но потом, пока я пишу код в вакууме юнит-тестов, я не тяну за собой все что есть у меня в проекте или возомжно этого еще нету. Допустим во время написания юнит тестов, усложняя свою структуру я дошел до того что мне нужен LRU-cache, но его еще нигде нету, его только предстоит написать и временно я его заменяю например std::vector и дальше продолжаю писать бизнес-логику, отдельно от все еще реального рисования.

Сообщение от Fulcrum_013 Сразу видно что именно считает в каком случае и насколько правильно.

Имея юнит-тесты можно просто не вести логи для абсолютно каждой команды внутри функции.

Сообщение от Fulcrum_013 И его задача визуализировать данные которые трудно воспринять при трассировке.

Да-да-да и еще раз да, подпишусь под каждым словом, это есть и это делают, юнит тесты идут как дополнительное, почему нельзя иметь и то, и другое?

Добавлено через 3 минуты

Сообщение от Fulcrum_013 Можно.

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

0

Сообщение от Azazel-San что позволяет мне делать в этом ключе все что угодно и позволяет добится максимальной независимости компонентов

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

Сообщение от Azazel-San Та же ECS - смысл которой добится этой независимости,

Ага знамо дело. Потом выскакивает конкретный гемор в плане как связать зависимые части обеспечивающие какой то определенный механизм.

Сообщение от Azazel-San а верно ли вы все делаете

Эти вопросы должны разруливаться на этапе проектирования архитектуры а не на этапе написания кода.

0

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

0

Сообщение от Azazel-San Так это все будет, но потом,

Потом оно нафиг не надо. Оно нужно именно на время отладки.

Сообщение от Azazel-San Имея юнит-тесты можно просто не вести логи для абсолютно каждой команды внутри функции.

И каким образом юнит тесты покажут где именно когда именно и какие именно данные неправильно переставились и что именно не срослось?

0

Сообщение от Fulcrum_013 не надо путать исключение ненужных зависимостей с обрубанием тотально вообще всех зависимостей.

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

Сообщение от Fulcrum_013 Потом выскакивает конкретный гемор в плане как связать зависимые части обеспечивающие какой то определенный механизм.

Пока у меня такого не случалось

Сообщение от Fulcrum_013 Эти вопросы должны разруливаться на этапе проектирования архитектуры а не на этапе написания кода.

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

0

Сообщение от Azazel-San больше делать рефакторинг я не собираюсь

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

Добавлено через 1 минуту

Сообщение от Azazel-San но мне кажется не всегда можно придвидеть все возможные варианты развития событий или изменения требований заказчика

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

0

Сообщение от Fulcrum_013 Оно нужно именно на время отладки.

А если нету возможности отладить код?

Сообщение от Fulcrum_013 И каким образом юнит тесты покажут где именно когда именно и какие именно данные неправильно переставились и что именно не срослось?

Ну они же отработали верно при ожидаемом поведении, соответственно если пошло что-то не так, значит кто-то из пользователей сделал что-то неверно, сейчас я понимаю что вы скажите нужно было стремится к универсальности и мы возвращаемся к обсуждению того же) не всегда же нужно писать универсальные функции, которыми будут пользоватся дргуие, но и локальные которые за границы вашей же программы никогда не выйдут. Почему тогда разработчики компиляторов не стремлятся до такой универсальности? А некоторый функционал если будет переписан программистом в отрыве от компилятора считается UB. Например мы хотим написать свой std::offsetof?

Добавлено через 2 минуты

Сообщение от Fulcrum_013 Вот так и получается вообще без рефакторинга.

круто, надеюсь когда так же смогу

0

Сообщение от Azazel-San Пока у меня такого не случалось

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

Сообщение от Azazel-San вот и имеем первый звоночек.

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

Добавлено через 3 минуты

Сообщение от Azazel-San но и локальные которые за границы вашей же программы никогда не выйдут

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

Добавлено через 1 минуту

Сообщение от Azazel-San А если нету возможности отладить код?

А что тогда тестировать?

Добавлено через 3 минуты
Так кстати о птичках что то на подобие юнит-тестов юзалось на компах шкафового базирования. Только оно не правильность кода тестировало а правильность счета процом. Причем на старте софтины. И кое что даже показывало к какому болту 3x4 нужно применить отладочный кувалдоид чтобы проц зафурычил как надо.

0

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

Думаю что бы дать внятный ответ, тут надо мнение кого-то более умного чем я

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

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

Сообщение от Fulcrum_013 А тем более что они абсолютно никак не помогают при отладке при которой все это тестируется вручную вдоль и поперек.

Незнаю мне помогает при дебаге моего кода.

Сообщение от Fulcrum_013 Вообще то любой алгоритм универсальная штука по определению алгоритма.

Не всегда же юнит-тестами тестируют именно алгоритм, а тестирование алгоритма возможно и не задание юнит-тестов?

Сообщение от Fulcrum_013 А что тогда тестировать?

Отдельные компоненты. В этом и суть как я понимаю юнит-тестов.

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

0