что такое game test framework в майнкрафт
Скачать карту Gametest Framework на Майнкрафт ПЕ
Скачайте карту Gametest Framework на Minecraft PE для устройств на ОС Андроид: найдите все зелёные маяки.
Отличные соревнования
Это шаблон мира, который можно будет использовать не только для одиночной игры, но и для игры по сети вместе с друзьями. Также на карте вы сможете встретить множество различных маяков. Вам нужно будет найти все зелёные.
Конечно, лучше всего играть вместе с друзьями, чтобы соревноваться. В таком случае вы сможете узнать, кто из вас быстрее думает и бегает. При этом многое будет зависеть и от удачи. К сожалению, данная карта не обновляется, это просто шаблон.
Но в дальнейшем есть вероятность, что автор добавит специальные режимы, в которых данная карта будет генерироваться случайным образом.
Для того чтобы включить данную карту, нужно будет сначала сделать то же самое в настройках. Рядом с каждым маяком будет специальная кнопка, которую нужно будет нажать.
Маленькие островки
Ещё отдельную изюминку данной игре придаёт тот факт, что все маяки будут располагаться на маленьких островках. Вам нужно будет прыгать с одного на другой. При этом ломать маяки не стоит. В таком случае есть вероятность того, что игра просто вылетит с ошибкой.
Ещё стоит отдельно заметить, что по умолчанию там будет стоять ночное время суток. Это, во-первых, делает данную карту более красивой. Во-вторых, так вам будет намного проще находить маяки, так как в темноте свечение каждого из них будет заметнее. Также проще будет отличать зелёные от красных.
Для Minecraft выпущен GameTest Framework — что это, и зачем он нужен
Раздел справочной информации на сайте Minecraft пополнился сразу тремя публикациями. Посвящены они, на первый взгляд, достаточно банальным вещам, которые не содержат какой-то новой информации. Например, две статьи — это описание команд и рассказ о возможности создания NPC в Minecraft Bedrock.
В целом все три статьи направлены на то, чтобы проинформировать читателя о существовании отдельного справочного портала для тех, кто хочет разрабатывать аддоны для Minecraft Bedrock.
И поэтому третья статья из серии публикаций значительно интереснее — в ней рассказывается о GameTest Framework, добавленном в Minecraft Bedrock.
Что такое GameTest Framework
Несмотря на то, что статья на сайте Minecraft преподносит GameTest Framework как нечто новое, сам фреймворк был интегрирован в Minecraft ещё в феврале 2021 г. в бета-версии 1.16.210.60.
Предназначен он для проведения тестов контента, добавляемого в игру разрабатываемыми аддонами, хотя при желании можно также тестировать и поведение стандартных игровых механик.
Тестирование и проверка того, как работает разрабатываемый аддон — это важнейшая часть создания игровых дополнений. Ты создаёшь что-то и проверяешь в игре, переделываешь и снова проверяешь в игре, и это могут быть сотни и тысячи проверок, на которые уходит времени не меньше, чем на саму разработку.
Фреймворк GameTest позволяет создавать такие небольшие проверки.
Для этого создаётся небольшой аддон, который содержит структуру — постройку, внутри которой нужно проводить тестирование. И скрипт, в котором описываются необходимые условия тестирования. Например, можно заспавнить определённых мобов, которые должны будут сразиться, а по результатам кто-то из них должен выжить. Или спрятаться. Или зарыться в землю. Тест будет считаться пройденным, если выполнено необходимое условие.
Таких тестов разработчик может написать столько, сколько ему нужно, для каждого элемента создаваемого аддона, и тогда на любом этапе разработки он будет знать, повлияло ли изменение на то, что было создано ранее.
Чтобы понять, как это работает, можете попробовать запустить и воспользоваться одним из встроенных тестов.
Как создавать собственные тесты
Встроенные тесты интересны, но основное назначение фреймворка — это тестирование собственных разработок. И тут уже одной командой не обойтись.
Нужно создавать собственный тестовый аддон, который включает в себя структуры и тестирующие скрипты.
Подробную инструкцию с примерами можно найти здесь.
Добавлю, что разработчиками Minecraft выпущено дополнение для редактора Visual Studio Code, которое добавляет средства отладки кода, выполняемого GameTest Framework, что, безусловно, значительно упростит работу над созданием аддонов.
Use script and structures to build scaffolds and tests
Introduction to the GameTest Framework
GameTest Framework is a new toolset available to creators to build and test any new content created by you. Within the world of Minecraft:Bedrock Edition, you can express infinite forms of gameplay and variability in your content. With all these creative possibilities, sometimes you may need additional tools to help validate that your experiences are running just as you expect it, and assist you as you customize aspects of the broader Minecraft environment.
Submitting and using GameTests can be a great way to establish and communicate the expected behavior you are looking for. As you build more complex worlds and adventures, use the GameTest Framework as a tool to validate facets of your content.
Requirements
To get started, you’ll want to begin with understanding how a behavior pack works within Minecraft. To read more about creating behavior packs, see this topic:
What’s a GameTest?
A GameTest is a miniature environment along with a set of starting conditions, such as a set of mobs or items. After that environment plays out in the Minecraft world for a period of time, a GameTest has conditional code that evaluates whether expected conditions were met. If a test passes, you will receive confirmation that everything is working as expected. When a test fails, you can observe and diagnose why it may have failed.
Let’s examine a potential use case for a GameTest. Let’s say that we want to validate that a minecart can make its way around curves and over a complex track when Redstone triggers it. We can build a GameTest for this case by building out a track, placing a minecart at the start of the track, and then power the track with a block of Redstone. We can then validate that the minecart reaches the end of its track within a reasonable time-frame. Minecraft includes a growing set of GameTests that test various basic situations in the Minecraft world. However, you can build your own GameTests to validate any changes you introduce.
Running tests within game
To run tests within a game, you’ll want to create a new world or start with a copy of your existing adventure and experience.
Within this GameTest world, you’ll want to ensure that cheats are enabled and that the GameTest Framework experiment is turned on. If you’ve created GameTest Framework tests within behavior packs, you’ll want to add those behavior packs in your world.
You’ll also likely want to specify some additional changes in your environment:
Once the world is loaded, use the /gametest command to run tests. Minecraft includes a growing number of GameTests for various situations, testing out the behaviors of Mobs, Villagers, Redstone, and more. You can see some of these tests as you work in the command line.
Note that Minecraft tests place structures in your environment, sitting on top of what may already exist. Don’t run GameTest Framework in the middle of your beautiful creations if you haven’t made a backup or copy first!
/gametest run minecarttests:turn
You will see the test run, and if the test completes successfully, you will see a «passed» completion message.
What’s Next?
Building sets of GameTests requires building out your GameTests via a behavior pack, and writing some simple JavaScript code. When building out your own tests, you will likely want to start a new test behavior pack that is just focused on adding additional GameTests.
To build and run your own GameTests, you must use the latest Beta versions of Minecraft (version 1.16.230+). See Minecraft Betas for more information.
Пост №6. Создание своего test framework-а с нуля. Часть 2
Всем привет! В предыдущем посте я начал рассказывать про создание test framework-а с нуля. В нем рассказал про выбор технологий, создание проекта в IDE, структуру и написание feature на языке Gherkin. Далее рассмотри создание Step-ов для реализации тестовой логики.
Итак начнем. Тестовая логика у нас прописана в feature-файлах. Для ее реализации необходимы Step-файлы. Они служат для перевода языка Gherkin, на язык программирования, в моем случае это Java. У IntelliJ IDEA есть замечательная настройка, позволяющая автоматически сгенерировать Step-файл для каждого из ключевых слов теста. На практие это выглядит так:
public void userSendLetterTo(String arg0) throws Throwable <
Так как Step не является исполняемым классом, то он расположен в package «java»
Теперь рассмотрим на примере структуру Step-файла:
На изображении выше видно, что все ключевые слова реализованы уже на Java языке. Причем нужно не забывать, что при написании реализации ключевых слов необходимо четко указывать в скобках точную фразу, написанную в feature, иначе Step просто не подцепится и компиляция и выполнение теста не произойдет.
Так как я изначально использовал методологию Page Object Pattern, то при написании Step-ов мне всего навсего необходимо было проинициализировать page-и, а дальше уже использовать функции, реализованные в самих page-ах. Самым разумным решением, на мой взгляд, это произвети инициализацию в Before-методе используя PageObjectFactory, а объявление page-ов методом «@Autowired @Lazy» (cucumber). @Lazy говорит о том, что применение и инициализация того или иного page-а будет происходить только в момент его вызова, а не при старте теста. Это отчасти облегчает тест и немного увеличивает его скорость прохождения.
Так же необходимо незабывать писать javadoc-и, так как никогда не известно кто в дальнейшем будет поддерживать ваши тесты. Да и вряд ли вы сами после написания 100-200 тестов будете четко помнить что именно реализует тот или иной метод.
Так же в package-е resources расположен еще один config-файл (target.properties), служащий для конфигурации адреса тестируемого приложения, данных пользователя и других часто используемых параметров.
Ну и для закрепления, ниже изображен еще один Step-файл
Итак, подведем итоги. В данном посте были рассмотрены правила и примеры написания Step-файлов, реализующих тестовую логику, прописанную в feature-файлах. Так же были рассмотрены конфигурационные файлы, используемые в тестах.
З.Ы. Всем огромное спасибо за внимание и интерес к моим постам. В следующем посте мы рассмотрим применение Page Object Pattern при описании элементов страниц.
Дубликаты не найдены
Реквестирую ссыль на репозиторий с данным проектом)
Данный проект лежит у меня локально)
буду благодарен, если смоожешь запушить его в публичный гит, ибо редко сталкивался с реализацией такого BDDшного подхода к автотестам, хотелось бы посмотреть на код
Извините конечно за непродуманность, просто это мой первый опыт создания подобных постов. Да и опятом перед такой аудиторией делюсь впервые)
С уважением, обезьяна-мануальщик, пытающаяся перерасти в автоматизатора)
Почему ява-кодеры такие тугие? Ну не нужны тут такие посты, это видно по их рейтингу.
На хабр не пускают, а посрать в интернетах «гайдами» нулевого уровня хочется?
Псс, парень. Не хочешь немного системных автотестов?
Хочу рассказать вам о проекте, который разрабатываю я с моим коллегой уже без малого три года, и который совсем недавно мы, неконец, зарелизили. Этот проект посвящен автоматизации тестов, и не абы каких, а системных.
Представьте, что вы написали приложение-калькулятор. Вы написали для него множество простейших тестов (проверили функции сложения, умножения, деления, и так далее). В сущности, вы написали unit-тесты (или, по-русски, модульные тесты).
Модульные тесты очень хороши, и оченнь многие ответственные программисты пишут достаточно много таких тестов для своих приложений. И это часто даёт им возможность спокойнее спать по ночам, зная, что их программа работает нормально, и хоть прямо сейчас её можно выкатывать довольным заказчикам.
Но так ли это? Ведь ваш калькулятор будет работать не просто так, а в конкретной операционной системе с конкретными настройками. А ещё у него может быть инстяллятор, который должен успешно отрабатывать, несмотря ни на что. А ещё он может зависеть от внешних библиотек, которые не всегда установлены в целевой системе.
И вот получается, что все модули по отдельности вроде бы протестированы, а на самом деле, спокойно спать всё ещё нельзя: ведь если калькулятор устанавливается и работает в Windows XP, то это абсолютно не означает, что он будет так же работать в Windows 7 или Windows 10.
И вот даже в самом простом калькуляторе вы сталкиваетесь с проблемой: как удостовериться, что мой калькулятор успешно устанавливается на Windows XP x32, Windows XP x64, Windows 7 x32, Windows 7 x64. И вот с этого момента вы начинаете, по сути, заниматься системным тестированием.
Чаще всего системные тесты проводят вручную. Обычно этим занимаются тестировщики (если они есть). Это проще всего, не требует особого умственного труда, но занимает кучу времени. Для крупных коммерческих проектов один полный прогон системных тестов может занимать несколько месяцев работы целого отдела.
Поэтому часто бывает так: в компании перед релизом проводят один полный прогон системных тестов, в ходе которого вылавливают N багов. Затем разработчики фиксят эти баги, а тесирование проверяет, что баги успешно закрыли. Но на второй полный прогон системных тестов времени уже просто не остаётся, поэтому компания просто надеется, что фиксы найденных багов не затронут другие части системы. Очень надёжно, правда?
Именно на решение этой проблемы мы направили свои усилия в своём проекте, который мы решили назвать Testo. В состав этой платформы входит специальный язык тестовый сценариев Testo-lang (да, мы написали целый язык для тестовых сценариев), который позволяет вам писать интуитивно-понятные сценарии для системных тестов.
Я не буду в этом посте очень долго распыляться о том, как это работает и устроено. Любители технических подробностей могут найти парочку наших статей на хабре (поиск по слову Testo-lang).
Также у нас есть сайт (тоже легко гуглится по Testo-lang), где вы можете скачать абсолютно бесплатно, без регистрации и СМС нашу платформу и пользоваться её сколько угодно (да, у нас есть платная версия, но она отличается от бесплатной только скоростью работы команды wait).
Больше примеров можно глянуть на Youtube-канале (тоже элементарно гуглится).
Введение в юнит-тестирование в Unity
Вам любопытно, как работает юнит-тестирование в Unity? Не знаете, что такое юнит-тестирование в целом? Если вы ответили положительно на эти вопросы, то данный туториал будет вам полезен. Из него вы узнаете о юнит-тестировании следующее:
Примечание: в этом туториале предполагается, что вы знакомы с языком C# и основами разработки в Unity. Если вы новичок в Unity, то изучите сначала другие туториалы по этому движку.
Что такое юнит-тест (Unit Test)?
Прежде чем углубляться в код, важно получить чёткое понимание того, что такое юнит-тестирование. Если говорить просто, то юнит-тестирование — это тестирование… юнитов.
Юнит-тест (в идеале) предназначен для тестирования отдельного «юнита» кода. Состав «юнита» может варьироваться, но важно помнить, что юнит-тестирование должно тестировать ровно один «элемент» за раз.
Юнит-тесты необходимо создавать для проверки того, что небольшой логический фрагмент кода в конкретном сценарии выполняется именно так, как вы ожидаете. Это может быть сложно понять, прежде чем вы начнёте писать собственные юнит-тесты, поэтому давайте рассмотрим пример:
Вы написали метод, позволяющий пользователю вводить имя. Метод написан так, что в имени не допускаются цифры, а само имя может состоять только из десяти или менее символов. Ваш метод перехватывает нажатие каждой клавиши и добавляет соответствующий символ в поле name :
Что здесь происходит:
Пример юнит-тестов
Прежде чем мы начнём реализовывать эти юнит-тесты, нужно тщательно продумать, что делают эти тесты, и придумать для них названия.
Посмотрите на показанные ниже примеры названий юнит-тестов. Из названий должно быть понятно, что они проверяют:
Каждый написанный вами юнит-тест является частью комплекса тестов. Комплекс тестов содержит все юнит-тесты, относящиеся к логической группе функционала (например, «юнит-тесты боя»). Если любой тест из комплекта не проходит проверку, то её не проходит весь комплект тестов.
Запуск игры
Откройте Crashteroids Starter project (скачать его можно отсюда), а затем откройте сцену Game из папки Assets / RW / Scenes.
Нажмите на Play, чтобы запустить Crashteroids, а затем нажмите на кнопку Start Game. Перемещайте космический корабль стрелками влево и вправо на клавиатуре.
Для выстрела лазерным лучом нажимайте пробел. Если луч попадёт в астероид, то счёт увеличится на единицу. Если астероид сталкивается с кораблём, то корабль взрывается и игра завершается (с возможностью начать заново).
Попробуйте немного поиграть и убедиться, что после столкновения астероида с кораблём появляется надпись Game Over.
Начинаем работу с Unity Test Runner
Теперь, когда мы знаем, как выполняется игра, настало время писать юнит-тесты, чтобы проверить, что всё работает как надо. Таким образом, если вы (или кто-то ещё) решите обновить игру, то будете уверены, что обновление не сломает ничего из работавшего раньше.
Чтобы писать тесты, сначала нужно узнать о Unity Test Runner. Test Runner позволяет выполнять тесты и проверять, проходятся ли они успешно. Чтобы открыть Unity Test Runner, выберите Window ▸ General ▸ Test Runner.
После того, как в новом окне откроется Test Runner, можно будет упростить себе жизнь, нажав на окно Test Runner и перетащив его на место рядом с окном Scene.
Подготовка NUnit и папок тестов
Test Runner — это предоставляемая Unity функция юнит-тестирования, но она использует фреймворк NUnit. Когда вы начнёте работать с юнит-тестами серьёзнее, то рекомендую изучить wiki по NUnit, чтобы узнать больше. Про всё необходимое на первое время будет рассказано в этой статье.
Для запуска тестов нам сначала нужно создать папку тестов, в которой будут храниться классы тестов.
В окне Project выберите папку RW. Посмотрите на окно Test Runner и убедитесь, что выбран PlayMode.
Нажмите кнопку с названием Create PlayMode Test Assembly Folder. Вы увидите, что в папке RW появится новая папка. Нас устроит стандартное название Tests, поэтому можно просто нажать Enter.
Возможно, вам интересно, что это за две разные вкладки внутри Test Runner.
Вкладка PlayMode используется для тестов, выполняемых в режиме Play (когда игра выполняется в реальном времени). Тесты вкладки EditMode выполняются вне режима Play, что удобно для тестирования таких вещей, как пользовательские behaviors в Inspector.
В этом туториале мы будем рассматривать тесты PlayMode. Но когда освоитесь, можете попробовать поэкспериментировать и с тестированием в EditMode. При работе с Test Runner в этом туториале всегда проверяйте, что выбрана вкладка PlayMode.
Что находится в комплекте тестов?
Как мы узнали выше, юнит-тест — это функция, тестирующая поведение небольшого конкретного фрагмента кода. Поскольку юнит-тест является методом, для его запуска он должен находиться в файле класса.
Test Runner обходит все файлы классов тестов и выполняет юнит-тесты из них. Файл класса, содержащий юнит-тесты, называется комплектом тестов (test suite).
В комплекте тестов мы логически подразделяем наши тесты. Мы должны разделять код тестов на отдельные логичные комплекты (например, комплект тестов для физики и отдельный комплект для боя). В этом туториале нам понадобится только один комплект тестов, и настало время его создать.
Подготовка тестовой сборки и комплекта тестов
Выберите папку Tests и в окне Test Runner нажмите на кнопку Create Test Script in current folder. Назовите новый файл TestSuite.
Кроме нового файла C# движок Unity также создаёт ещё один файл под названием Tests.asmdef. Это файл определения сборки (assembly definition file), который используется для того, чтобы показать Unity, где находятся зависимости файла теста. Это нужно, потому что код готового приложения содержится отдельно от тестового кода.
Если у вас возникла ситуация, когда Unity не может найти файлы тестов или тесты, то убедитесь, что существует файл определения сборки, в который включён ваш комплект тестов. Следующим шагом будет его настройка.
Чтобы код тестов имел доступ к классам игры, мы создадим сборку кода классов и зададим ссылку в сборке Tests. Нажмите на папку Scripts, чтобы выбрать её. Нажмите правой клавишей на эту папку и выберите Create ▸ Assembly Definition.
Назовите файл GameAssembly.
Нажмите на папку Tests, а затем на файл определения сборки Tests. В Inspector нажмите на кнопку плюс под заголовком Assembly Definition References.
Вы увидите поле Missing Reference. Нажмите на точку рядом с этим полем, чтобы открыть окно выбора. Выберите файл GameAssembly.
Вы должны увидеть файл сборки GameAssembly в разделе ссылок. Нажмите на кнопку Apply, чтобы сохранить эти изменения.
Если вы не выполните эти действия, то не сможете ссылаться на файлы классов игры внутри файлов юнит-тестов. Разобравшись с этим, можно приступать к коду.
Пишем первый юнит-тест
Дважды нажмите на скрипт TestSuite, чтобы открыть его в редакторе кода. Замените весь код на такой:
Какие тесты нам нужно написать? Честно говоря, даже в такой крошечной игре, как Crashteroids, можно написать довольно много тестов для проверки того, что всё работает как надо. В этом туториале мы ограничимся только ключевыми областями: распознаванием коллизий и базовой игровой механикой.
Примечание: когда дело доходит до написания юнит-тестов продукта уровня продакшена, стоит уделить достаточно времени, чтобы учесть все граничные случаи, которые нужно протестировать во всех областях кода.
В качестве первого теста неплохо будет проверить, действительно ли астероиды движутся вниз. Им будет сложно столкнуться с кораблём, если они будут от него отдаляться! Добавим в скрипт TestSuite следующий метод и частную переменную:
Здесь всего несколько строк кода, но они выполняют множество действий. Так что давайте остановимся и разберёмся с каждой частью:
Прохождение тестов
Отлично, вы написали свой первый юнит-тест, но как узнать, что он работает? Разумеется, с помощью Test Runner! В окне Test Runner раскройте все строки со стрелками. Вы должны увидеть тест AsteroidsMoveDown в списке с серыми кружками:
Серый кружок означает, что тест пока не выполнялся. Если тест был запущен и пройден, то рядом показывается зелёная стрелка. Если тест завершился с ошибкой, то рядом с ним будет отображён красный X. Запустим тест, нажав на кнопку RunAll.
При этом создастся временная сцена и будет запущен тест. После завершения вы должны увидеть, что тест пройден.
Вы успешно написали первый юнит-тест, утверждающий, что создаваемые астероиды движутся вниз.
Примечание: прежде чем начать писать собственные юнит-тесты, вам нужно понять реализацию, которую вы тестируете. Если вам любопытно, как работает тестируемая вами логика, то изучите код в папке RW / Scripts.
Использование интеграционных тестов
Прежде чем двигаться глубже в кроличью нору юнит-тестов, самое время рассказать, что такое интеграционные тесты, и чем они отличаются от юнит-тестирования.
Интеграционные тесты — это тесты, проверяющие как работают «модули» кода совместно. «Модуль» — это ещё один нечёткий термин. Важное отличие заключается в том, что интеграционные тесты должны тестировать работу ПО в настоящем продакшене (т.е. когда игрок по-настоящему играет в игру).
Допустим, вы сделали игру с боями, где игрок убивает монстров. Можно создать интеграционный тест, чтобы убедиться, что когда игрок убивает 100 врагов, открывается достижение («ачивка»).
Этот тест затронет несколько модулей кода. Скорее всего, он будет касаться физического движка (распознавание коллизий), диспетчеров врагов (отслеживающих здоровье врага и обрабатывающих урон, а также переходящих к другим связанным событиям) и трекера событий, отслеживающего все сработавшие события (например «монстр убит»). Затем, когда настанет время разблокировки достижения, он может вызвать диспетчер достижений.
Интеграционный тест будет симулировать игрока, убивающего 100 монстров, и проверять, разблокируется ли достижение. Он очень отличается от юнит-теста, потому что тестирует крупные компоненты кода, работающие совместно.
В этом туториале мы не будем изучать интеграционные тесты, но это должно показать разницу между «юнитом» работы (и то, зачем её юнит-тестируют) и «модулем» кода (и то, зачем его тестируют интеграционно).
Добавление теста в комплект тестов
Следующий тест будет тестировать конец игры, когда корабль сталкивается с астероидом. Открыв в редакторе кода TestSuite, добавьте под первым юнит-тестом показанный ниже тест и сохраните файл:
Мы уже видели бОльшую часть этого кода в предыдущем тесте, но здесь есть некоторые отличия:
На этот раз мы запустим вместо всего комплекта тестов только этот. Нажмите на GameOverOccursOnAsteroidCollision, а затем на кнопку Run Selected.
И вуаля, мы прошли ещё один тест.
Этапы настройки и разрушения
Вы могли заметить, что в двух наших тестах есть повторяющийся код: там, где создаётся игровой объект Game и где задаётся ссылка на скрипт Game:
Также вы заметите, что повтор есть в уничтожении игрового объекта Game:
При тестировании такое случается очень часто. Когда дело доходит до запуска юнит-тестов, то на самом деле существует два этапа: этап «настройки» (Setup) и этап «разрушения» (Tear Down).
Весь код внутри метода Setup будет выполняться до юнит-теста (в этом комплекте), а весь код внутри метода Tear Down будет выполняться после юнит-теста (в этом комплекте).
Настало время упростить нашу жизнь, переместив код setup и tear down в специальные методы. Откройте редактор кода и добавьте следующий код в начало файла TestSuite, прямо перед первым атрибутом [UnityTest]:
Атрибут SetUp указывает, что этот метод вызывается до выполнения каждого теста.
Затем добавим следующий метод и сохраним файл:
Атрибут TearDown указывает, что этот метод вызывается после выполнения каждого теста.
Подготовив код настройки и разрушения, удалим строки кода, присутствующие в этих методах, и заменим их вызовами соответствующих методов. После этого код будет выглядеть так:
Тестируем Game Over и стрельбу лазером
Подготовив упрощающие нашу жизнь методы настройки и разрушения, можно приступить к добавлению новых тестов, в которых они используются. Следующий тест должен проверять, что когда игрок нажимает New Game, значение gameOver bool не равно true. Добавьте такой тест в конец файла и сохраните его:
Это уже должно казаться вам привычным, но стоит упомянуть следующее:
Утверждение о движении лазерного луча
Следующим тестом нужно добавить тест того, что выстреливаемый кораблём лазерный луч летит вверх (аналогично первому написанному нами юнит-тесту). Откройте в редакторе файл TestSuite. Добавьте следующий метод и сохраните файл:
Вот что делает этот код:
Теперь вы уже должны начать разбираться, как всё устроено, поэтому настало время добавить последние два теста и завершить туториал.
Проверка того, что лазер уничтожает астероиды
Далее мы убедимся, что при попадании лазер уничтожает астероид. Откройте редактор и добавьте в конец TestSuite следующий тест, а потом сохраните файл:
Вот как это работает:
Тестировать или не тестировать — вот в чём вопрос
Решение придерживаться юнит-тестов — непростое решение, и к нему не стоит относиться легкомысленно. Однако преимущества тестов стоят вложенных усилий. Существует даже методология разработки, называющаяся разработкой через тестирование (Test Driven Development, TDD).
Работая в рамках TDD, вы пишете тесты до написания самой логики приложения. Сначала вы создаёте тесты, убеждаетесь, что программа их не проходит, а затем пишете только код, предназначенный для прохождения тестов. Пусть это очень отличающийся подход к кодингу, но он гарантирует, что вы пишете код пригодным для тестирования образом.
Помните об этом, когда приступите к работе над следующим проектом. Но пока время писать собственные юнит-тесты, для которых нужна игра, которую мы вам и предоставили.
Примечание: нужно принять решение — тестировать только общие методы, или ещё и частные. Некоторые люди считают, что частные методы должны тестироваться только через использующие их общие методы. Это может сделать «юнит» кода, который нужно протестировать, довольно большим и может оказаться нежелательным. С другой стороны, тестирование частных методов может быть проблематичным и требовать особых фреймворков или инструментов рефлексии. Каждый из вариантов имеет свою плюсы и минусы, рассмотрение которых не входит в рамки данного туториала. В этом туториале все методы сделаны общими, чтобы их проще было отслеживать, поэтому не берите его в качестве примера при написании кода для продакшена.
Тестирование может быть большим вложением усилий, поэтому стоит рассмотреть достоинства и недостатки добавления юнит-тестирования в ваш проект:
Достоинства юнит-тестирования
У юнит-тестирования есть множество важных плюсов, в том числе и такие:
Недостатки юнит-тестирования
Однако у вас может и не быть времени или бюджета на юнит-тестирование. Вот его недостатки которые нужно учесть:
Тестирование того, что при уничтожении астероидов увеличивается счёт
Настало время писать последний тест. Откройте редактор кода, добавьте показанный ниже код в конец файла TestSuite и сохраните его:
Это важный тест, проверяющий, что когда игрок уничтожает астероид, счёт увеличивается. Вот из чего он состоит:
Потрясающе! Все тесты пройдены.
Куда двигаться дальше?
В статье мы рассмотрели большой объём информации. Если вы хотите сравнить свою работу с финальным проектом, то посмотрите его в архиве, ссылка на который также указана в начале статьи.
Из этого туториала вы узнали, что такое юнит-тесты и как писать их в Unity. Кроме того, вы написали шесть юнит-тестов, которые успешно прошёл код, и познакомились с некоторыми из плюсов и минусов юнит-тестирования.
Чувствуете себя уверенно? Тогда можно написать ещё множество тестов. Изучите файлы классов игры и попробуйте написать юнит-тесты для других частей кода. Подумайте над добавлением тестов для следующих сценариев:
Также прочитайте документацию NUnit, чтобы узнать больше о фреймворке NUnit.
И не стесняйтесь делиться своими мыслями и вопросами на форумах.