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.
Скачать карту 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
Google testing framework (gtest)
Ключевые понятия
Ключевым понятием в Google test framework является понятие утверждения (assert). Утверждение представляет собой выражение, результатом выполнения которого может быть успех (success), некритический отказ (nonfatal failure) и критический отказ (fatal failure). Критический отказ вызывает завершение выполнения теста, в остальных случаях тест продолжается. Сам тест представляет собой набор утверждений. Кроме того, тесты могут быть сгруппированы в наборы (test case). Если сложно настраиваемая группа объектов должна быть использована в различных тестах, можно использовать фиксации (fixture). Объединенные наборы тестов являются тестовой программой (test program).
Утверждения (assertion)
Утверждения, порождающие в случае их ложности критические отказы начинаются с ASSERT_, некритические — EXPECT_. Следует иметь ввиду, что в случае критического отказа выполняется немедленный возврат из функции, в которой встретилось вызвавшее отказ утверждение. Если за этим утверждением идет какой-то очищающий память код или какие-то другие завершающие процедуры, можете получить утечку памяти.
Имеются следующие утверждения (некритические начинаются не с ASSERT_, а с EXPECT_):
Простейшие логические
Сравнение
Сравнение строк
Проверка на исключения
Проверка предикатов
В случае ложности утверждения, выдаются данные, использованные в утверждении. Кроме того, можно задать собственный комментарий:
Можно использовать расширенные наборы символов (wchar_t) как в комментариях, так и в утверждениях, касающихся строк. При этом выдача будет в UTF-8 кодировке.
Тесты (tests)
Для определения теста используется макрос TEST. Он определяет void функцию, в которой можно использовать утверждения. Как отмечалось ранее, критический отказ вызывает немедленный возврат из функции.
TEST принимает 2 параметра, уникально идентифицирующие тест, — название тестового набора и название теста. В рамках одного и того же тестового набора названия тестов не должны совпадать. Если название начинается с DISABLED_, это означает, что вы пометили тест (набор тестов) как временно не используемый.
Можно использовать утверждения не только в составе теста, но и вызывать их из любой функции. Имеется лишь одно ограничение — утверждения, порождающие критические отказы не могут быть вызваны из не void функций.
Фиксации (fixtures)
Случается, что объекты, участвующие в тестировании, сложно настраиваются для каждого теста. Можно задать процесс настройки один раз и исполнять его для каждого теста автоматически. В таких ситуациях используются фиксации.
Фиксация представляет собой класс, унаследованный от ::testing::Test, внутри которого объявлены все необходимые для тестирования объекты при этом в конструкторе либо функции SetUp() выполняется их настройка, а в функции TearDown() освобождение ресурсов. Сами тесты, в которых используются фиксации, должны быть объявлены с помощью макроса TEST_F, в качестве первого параметра которого должно быть указано не название набора тестов, а название фиксации.
Для каждого теста будет создана новая фиксация, настроена с помощью SetUp(), запущен тест, освобождены ресурсы с помощью TearDown() и удален объект фиксации. Таким образом каждый тест будет иметь свою копию фиксации «не испорченную» предыдущим тестом.
В некоторых случаях создание тестируемых объектов является очень дорогой операцией, а тесты не вносят никаких изменений в объекты. В таком случае можно не создавать фиксации заново для каждого теста, а использовать распределенную фиксацию с глобальным SetUp()и TearDown(). Фиксация автоматически становится распределенной, если в классе имеется хотя бы один статический член. Статические функции SetUpTestCase() и TearDownTestCase() будут вызываться для настройки объекта и освобождения ресурсов соответственно. Таким образом, набор тестов перед первым тестом вызовет SetUpTestCase(), а после последнего TearDownTestCase().
Если существует потребность в SetUp() и TearDown() для всей программы тестирования, а не только для набора теста, необходимо создать класс-наследник для ::testing::Environment, переопределить SetUp() и TearDown() и зарегистрировать его с помощью функции AddGlobalTestEnvironment.
Запуск тестов
Объявив все необходимые тесты, мы можем запустить их с помощью функции RUN_ALL_TESTS(). Функцию можно вызывать только один раз. Желательно, чтобы тестовая программа возвращала результат работы функции RUN_ALL_TESTS(), так как некоторые автоматические средства тестирования определяют результат выполнения тестовой программы по тому, что она возвращает.
Флаги
Вместо заключения
В данном посте я кратко пробежался по основным функциям Google Test Framework. За более подробными сведениями следует обратиться к документации. Оттуда вы сможете почерпнуть информацию о ASSERT_DEATH используемом при падении программы, о ведении дополнительных журналов, о параметризованных тестах, настройке вывода, тестировании закрытых членов класса и многое другое.
UPD: По справедливому замечанию хабрапользователя nikel добавлена краткая инофрмация по использованию флагов.
UPD 2: Исправление разметки после изменений на Хабре (нативный тег source).
Пост №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-канале (тоже элементарно гуглится).