Очень редкая тема в контексте Unreal engine 4! Спасибо большое!!!

@LifeEXECode

2 жыл бұрын

Пожалуйста! В следующем видео начнем писать тесты.

Спасибо! Очень полезно!

Ещё одно отличное видео по тестированию в Unreal. Спасибо!

@LifeEXECode

2 жыл бұрын

Пожалуйста!

Отличная теоретическая основа, лучше чем у нас в универе рассказывали)

Даже философскую часть добавил, как же это правильно.

Спасибо Вам большое за такие шикарные лекции!

Спасибо, очень круто что вы так подробно рассказываете!

Очень интересное видео, ждем продолжение!

Отличное видео, ждала выхода данного блока)

Молодцы, даёте достаточно сильную базу понятным языком.

"Или брат Павла Дурова" - тонко подмечено)

Боже, какой же ты крутой тип. Хочу чтобы ты был моим лучшим другом и мы работали в одной команде!!! ❤‍🔥🤜🤛🙌 А есть где-то уже материалы этого курса, например на udemy, по темам: ∎ Интеграционное тестирование. Симуляция ввода Input Component ∎ Functional screenshot test ∎ Публикация отчета по тестам. Test Report ∎ Метрики тестирования. Тестовое покрытие. OpenCppCoverage ∎ Создание работы в Jenkins для автоматического запуска тестов с публикацией отчетов ∎ Slack. Email notifications ∎ Jenkins pipelines мне как раз вот это сейчас максимально актуально, а на какале его пока что нет👻

@LifeEXECode

2 жыл бұрын

Хах, спасибо) Это грядущие лекции, они еще не записаны. Легенда: ✔- видео на канале ➡ - текущее видео ⬜ - невыпущенная лекция

@mikesyvovol2042

2 жыл бұрын

@@LifeEXECode спасибо, да я понимаю, думал может ты их уже где-то за денюжку выложил 🤷🏻‍♂️ Ну, тогда надеюсь что будет что по существу добавить, к моменту выхода. 🔥

Очень интересную тему вы начали. Спасибо!

@LifeEXECode

2 жыл бұрын

Пожалуйста! Рад, что вам нравится (=

спасибо за шикарное видео

@LifeEXECode

2 жыл бұрын

Пожалуйста!

наконец то кто-то пояснил для чего const с переменными

Юрий, доброе утро! У вас есть опыт автоматизации тестирования сетевого кода?

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

@LifeEXECode

2 жыл бұрын

"Интеграционные тесты проверяют взаимодействие двух бизнес компонентов, а не технических(классы)." - Не согласен со второй частью про классы. Абсолютно обычная ситуация, что у вас есть две подсистемы в игровом проекте и нужно протестировать их взаимодействие. Примеры: 1. Компоненты: система модификации оружия; система пикапов различных частей оружия; AI патрулирования и нахождения пикапов. Все системы покрыты unit тестами, которые корректно выполняются и разработаны отдельными командами. Вполне себе можно создать интеграционный изолированный тест на карте с разбросанными частями оружия, которые должны быть подобраны NPC для получения детерминированной модификации боекомплекта и наловить багов на этом. 2. Компоненты: система дверей, лифтов и прочее, которые может открыть персонаж; модельная логика квеста. Интеграционный тест: в зависимости от прогресса по квесту, определённые двери, лифты становятся доступны для персонажа. + все это естественно можно оттестировать белым ящиком. "Ещё тестирование стабильности, стресс тестинг, нагрузочное тестирование это всё подразделы тестирования производительности." - Я бы не стал так однозначно утверждать. В видео говорил, что это вопрос терминологии, как вы будете классифицировать типы тестирования. Зависит от проекта, платформы, фреймворка и т.п. Простейший пример: система корректно работает, но везде используются жадные алгоритмы. Соответственно система стабильна, но производительность слабая.

@abrampetrenko7767

2 жыл бұрын

@@LifeEXECode Про интеграционные тесты - конечно в случае когда класс настолько высокоуровневый что торчит наружу и его можно проверить белым ящиком то согласен, но это должен быть класс чуть ли не уровня страницы. Если нет и для проверки нужно лезть в код то это уже не подпадает под интеграционное тестирование. Тут можно привести стандартный пример: логин форма. Чтобы залогиниться нужно провзаимодействовать с кучей классов: ввести логин, пароль, нажать кнопку логина, при этом мы можем проверять что например встроенная подсказка работает и т.д. и это всё ещё будет компонентная проверка, а не интеграционная. А вот когда мы нажали логин и проверяем что открылась домашняя страница то это уже самый простой интеграционный тест, то есть произошло взаимодействие компонентов именно с точки зрения пользователя, а не разработчика. И ещё не забываем что интеграционные тесты ведь также могут использовать заглушки, совсем как юниты, и это нормально, но это просто к слову. Насчёт терминологии в перфоманс тестинге она как раз уже вполне устоявшаяся, в отличие от скажем функционального тестирования где действительно по три термина обозначают одно и то же. Это происходит из-за того что в функциональное тестирование автоматизация пришла относительно недавно и она тут ещё не устоялась. А вот перфоманс тестирование изначально было сильно автоматизируемым процессом поэтому там всё давно стабильно. Насчёт последнего примера: если система удовлетворяет требуемой производительности (нагрузочное, стресс и и.д.) то абсолютно всё равно насколько жадные там используются алгоритмы, тестирование такими категориями не руководствуется. В вашем случае если производительность системы будет удовлетворять требованиям то и хорошо, если нет, то это будет отловлено тестированием производительности, например стресс тестом который покажет что двух юзеров система уже не тянет, а нужно тянуть хотя бы трёх.