Я никогда не занимался Разработкой через тестирование, потому что когда вы работаете над графическими видеоиграми, это просто не очень практично, учитывая сложность цикла взаимодействия с игроком.
Основная идея TDD состоит в том, чтобы написать тест, описывающий желаемую функциональность и изначально не пройденный. Затем вы пишете настоящий программный код, удовлетворяющий требованиям теста, до тех пор, пока тест не пройдет (и только до тех пор). Так, например, чрезвычайно простым тестом может быть:
function TestAddition() : boolean
{
return (Add(1, 1) == 2);
}Если вы запустите этот тест прямо сейчас, он потерпит неудачу, потому что Add() еще не объявлено. Итак, затем вы должны написать некоторый фактический программный код, чтобы пройти тест:
function Add(a : number, b : number)
{
return a + b;
}И теперь, когда вы запускаете тест, он возвращает true, что (в этом примере) означает, что он пройден. Если позже вы рефакторили функцию Add() и допустили ошибку:
function Add(a : number, b : number)
{
return a - b; // Actually subtracting, because reasons...?
}… вы поймаете это, как только запустите тестовую батарею, потому что TestAddition() теперь вернет false, то есть отказ.
Более сложные тесты будут «имитировать» некоторое состояние или пользовательский ввод, что приводит к одной общей жалобе на TDD: многословие самих тестов. Но преимущества долгосрочной стабильности кода, вероятно, перевешивают эти затраты, особенно если тесты и программный код хорошо разделены и хорошо организованы.
Однако особенность использования TDD для графических игр, и причина, по которой я никогда не принимал его в качестве регулярной практики, заключается в том, что ошибки в графических играх, как правило, появляются из-за очень сложных взаимодействий состояния и ввода игрока, которые на самом деле невозможно исправить. описать в этих видах функциональных тестов.
Подумайте: как вы имитируете автоматизированный тестовый пример для ошибки, вызванной тем, что игрок проходит уровень до определенного места в определенное время, а затем видит графические артефакты и глюки, появляющиеся на ближайших текстурах окружающей среды? Вам понадобится какой-то способ определить, как должен выглядеть визуализированный кадр, и какой-то способ зафиксировать, как он выглядит на самом деле, и какой-то способ сравнить эти две учетные записи. за тот факт, что анимированные элементы (скажем, качающаяся трава) могут не находиться в идеальном по пикселям идентичном состоянии от теста к тесту, но эти различия — и только эти различия — не имеют отношения к прохождению или провалу этого теста.
Кроме того, вам нужно смоделировать какую-то систему, которая эмулирует элементы управления игрока, чтобы аватар игрока всегда бежал в это место на уровне с этим временем. Что, если дизайнер изменит уровень, и вдруг ваш тест сломается не из-за ошибки, на которую он тестируется, а из-за того, что ваш код управления эмулируемым игроком не может справиться с тем фактом, что теперь ему нужно перепрыгнуть препятствие, которое он не знает есть?
Что, если вы не знаете, какие места на уровне демонстрируют такое поведение, а только то, что их, вероятно, много? Вы пишете тесты для посещения множества разных мест? Вы выбираете эти места наугад или по каким-то правилам? Может ли ваш набор тестов получить достаточно информации об уровне, чтобы даже применить эти правила? Сколько мест вы тестируете?
И теперь, когда вы запускаете сотни или тысячи действительно сложных тестов, зависящих от времени, сколько времени занимает выполнение вашего набора тестов и насколько это мешает вашему повседневному циклу разработки?
По моему опыту, такого рода проблемы тестирования имеют тенденцию выходить из-под контроля быстрее, чем их можно описать.
Однако Fractive — это не графические игры; по сути, это просто инструмент, который определенным образом преобразует данные (Markdown и Javascript) в другие данные (HTML). И этот материал поддается детерминистической проверке, и это действительно разумно.
Вчера я написал о действительно глупой проблеме Unreal. Я потратил слишком много усилий на отладку, в основном из-за запутанного представления множественных состояний ошибок. Это то, что происходит, когда взаимодействие с пользователем не тщательно и вдумчиво не тестируется, и я определенно хочу избежать с помощью Fraactive.
Текущая версия Fraactive в основном является доказательством концепции: она выполняет свою работу, но все еще может ломаться странными способами, которые не так удобны для автора, как мне бы хотелось. Так что следующим пунктом нашей дорожной карты является ужесточение, а это означает принятие чего-то хотя бы отчасти наподобие TDD. Мне также нужно провести всестороннюю проверку качества того, что уже есть, проверяя как можно больше различных состояний ошибок, вызванных автором, таких как синтаксические ошибки в исходном тексте/сценарии или ссылки на несуществующие разделы и функции, и гарантируя, что они присутствуют в таким образом, чтобы ошибка была ясно сообщена, а необходимое исправление было легко понято.
Я хочу создать довольно легкую среду тестирования, которую легко расширять новыми тестами и легко интегрировать в конвейер сборки на основе npm. Я хотел бы, чтобы решение — или несколько решений, работающих согласованно — позволяло писать предварительные тесты, как в классическом TDD, а также иметь возможность писать тесты, которые воспроизводят обнаруженные ошибки и служат как подтверждением исправления ошибок. и автоматические регрессионные проверки в будущем.
Мне не нужен какой-то монолитный тестовый фреймворк, который требует больше времени для изучения и реализации, чем сам проект, для которого он выполняет тесты. Я не против написать что-то новое, но синдром «не здесь изобрели» тоже вызывает опасения. В тех небольших поисках, которые я провел в сфере TDD, я видел несколько наборов тестов, которые выглядят как изучение совершенно новых языков программирования только для того, чтобы написать тесты, и такие вещи меня довольно сильно отталкивают, верно. в настоящее время. По крайней мере, потребуется убедительный аргумент, чтобы заставить меня подумать о принятии тестовой среды такого рода.
Это станет для меня областью исследований, поскольку, как я уже сказал в начале этого поста, я никогда раньше не занимался TDD или чем-то еще на его орбите. Так что любые предложения или рекомендации от других разработчиков Javascript/TypeScript определенно будут приветствоваться!
