Сейчас выбираю движок для 2d игры, много читал про доступные варианты, в том числе про то, что для простых 2d игр ue тянет слишком много либ, чрезмерно перегружая билд и итоговое приложение, что также влияет на конверсию.
На unity достаточно быстро сделал демку игры, UE даже не разбирал практически.
Как считаете, есть ли смысл потратить время и поработать также и с UE, как с более перспективным решением? И является ли он перспективным в контексте 2d вообще?
На всякий - C# или C++ выбор для меня не существеннен, есть опыт коммерческой разработки на обоих, достаточный для реализации простой игры.
Вы, наверное, шутите? Автоматика — как средство многократного и быстрого тестирования нужна именно там, где все меняется. Чтоб проверить не сломали ли чего изменения. То, что не будет меняться — можно проверить и вручную. Изредка.
Отличный комментарий, спасибо. Здесь как раз совершенно наглядна разница двух основных подходов к выбору области автоматизации (когда писал статью — обдумывал, стоит ли это расписывать, видимо стоило).
По сути очень многое в выборе подхода зависит от ресурсов, имеющихся у команды и сложности самого проекта.
Для проектов, где я развёртывал автоматизацию наиболее слабым местом была именно регрессия, даже тестирование в дельта-окрестности отдельных задач нового релиза требовало большого времени на разные варианты проверки (в основном — тесты с высокой вариативностью входных данных), и ресурсы тестировщиков тратились именно на эти сложные проверки. Закрытие их авто-тестами практически закрыло проблему регрессии.
Здесь важно отметить, что мало изменяемый код не означает — мало используемый. Понятно, что автоматизировать стоит в первую очередь критические точки проекта.
В то же время, совершенно разумный подход — при отсутствии проблем в мало изменяемых областях и при наличии ресурсов — автоматизировать часто изменяемый код — с, как вы верно отметили, целью проверки его на валидность после внесённых изменений. Подход можно рекомендовать компаниям, где автотестирование профессионально отлажено (либо есть профессиональный специалист), и изменение повалившихся тестов при изменении функционала не занимает долгого времени и сил.
У начинающих специалистов, для которых, в основном статья и написана, подобный подход может отнимать слишком много времени (впрочем, всё, естественно, зависит от человека).
И опять на те же грабли, оцениваем автоматизированное тестирование по отношению ручному. Да еще и эффективность в отрыве от результативности. Это разные виды тестирования с разными тактическими целями и задачами. Автоматизация — во многом — скорость и воспроизводимость.
В статье указано, что эта оценка — примерная и её стоит использовать в том случае, когда данные о результативности автоматизации по данному модулю либо малы, либо отсутствуют, по сути — когда это будет предварительная оценка автоматизации на основании приблизительных данных из других модулей и/или ручного тестирования на проекте. На основании вашего вопроса чуть подробнее раскрыл описанное в статье.
Эта оценка нужна скорее для того, чтобы начинающий специалист мог понять и обосновать руководству, нужна ли вообще автоматизация на проекте, или ну её, руками справимся быстрее.
Функциона́л — это отображение, заданное на произвольном множестве.
Не следует путать с функциональностью — совокупностью возможных вариантов использования или возможных действий выполняемых неким объектом (программой).
Функционал в контексте функциональности — часто используемый жаргонизм и элемент сленга.
Впрочем, с учётом того, что это режет глаза — почистил текст.
Статья понравилась, большое внимание уделено подготовке, описаны роли в контексте автоматизации — это редко где встретишь. Спасибо.
Вам большое спасибо за комментарий, как появится время — раскрою вопрос с выбором цели автоматизации подробнее.
Спасибо, Вы написали любопытную статью, можно будет попробовать использовать на одном из проектов.
Но, конкретно здесь указаны не недостатки webdriver'а в целом, как решения (о чём написано в предыдущей главе), а большее удобство использования связки Karma + Protractor для тестирования AngularJS бекэнда.
И опять же в третьих — две главы о выборе и использования инструментария здесь скорее проходят примером решения для конкретного проекта, поскольку само руководство немного о другом. :)
Если не возражаете, задам вопрос :)
Сейчас выбираю движок для 2d игры, много читал про доступные варианты, в том числе про то, что для простых 2d игр ue тянет слишком много либ, чрезмерно перегружая билд и итоговое приложение, что также влияет на конверсию.
На unity достаточно быстро сделал демку игры, UE даже не разбирал практически.
Как считаете, есть ли смысл потратить время и поработать также и с UE, как с более перспективным решением? И является ли он перспективным в контексте 2d вообще?
На всякий - C# или C++ выбор для меня не существеннен, есть опыт коммерческой разработки на обоих, достаточный для реализации простой игры.
Заранее спасибо за ответ :)
Отличный комментарий, спасибо. Здесь как раз совершенно наглядна разница двух основных подходов к выбору области автоматизации (когда писал статью — обдумывал, стоит ли это расписывать, видимо стоило).
По сути очень многое в выборе подхода зависит от ресурсов, имеющихся у команды и сложности самого проекта.
Для проектов, где я развёртывал автоматизацию наиболее слабым местом была именно регрессия, даже тестирование в дельта-окрестности отдельных задач нового релиза требовало большого времени на разные варианты проверки (в основном — тесты с высокой вариативностью входных данных), и ресурсы тестировщиков тратились именно на эти сложные проверки. Закрытие их авто-тестами практически закрыло проблему регрессии.
Здесь важно отметить, что мало изменяемый код не означает — мало используемый. Понятно, что автоматизировать стоит в первую очередь критические точки проекта.
В то же время, совершенно разумный подход — при отсутствии проблем в мало изменяемых областях и при наличии ресурсов — автоматизировать часто изменяемый код — с, как вы верно отметили, целью проверки его на валидность после внесённых изменений. Подход можно рекомендовать компаниям, где автотестирование профессионально отлажено (либо есть профессиональный специалист), и изменение повалившихся тестов при изменении функционала не занимает долгого времени и сил.
У начинающих специалистов, для которых, в основном статья и написана, подобный подход может отнимать слишком много времени (впрочем, всё, естественно, зависит от человека).
В статье указано, что эта оценка — примерная и её стоит использовать в том случае, когда данные о результативности автоматизации по данному модулю либо малы, либо отсутствуют, по сути — когда это будет предварительная оценка автоматизации на основании приблизительных данных из других модулей и/или ручного тестирования на проекте. На основании вашего вопроса чуть подробнее раскрыл описанное в статье.
Эта оценка нужна скорее для того, чтобы начинающий специалист мог понять и обосновать руководству, нужна ли вообще автоматизация на проекте, или ну её, руками справимся быстрее.
Функционал в контексте функциональности — часто используемый жаргонизм и элемент сленга.
Впрочем, с учётом того, что это режет глаза — почистил текст.
Вам большое спасибо за комментарий, как появится время — раскрою вопрос с выбором цели автоматизации подробнее.
1. Бэкграунд
2. Karma
Но, конкретно здесь указаны не недостатки webdriver'а в целом, как решения (о чём написано в предыдущей главе), а большее удобство использования связки Karma + Protractor для тестирования AngularJS бекэнда.
И опять же в третьих — две главы о выборе и использования инструментария здесь скорее проходят примером решения для конкретного проекта, поскольку само руководство немного о другом. :)