Comments 3
2016 год… Не рановато? Может ещё пусть статья вылежится? )
Больше похоже на набор заклинаний, которые должен выучить привезенный из деревни пастух-индус чтобы получить работу.
Изложу своё мнение, основанное на личном опыте комплексного внедрении автоматического тестирования и end-to-end тестов в CI\CD для очень крупного веб. приложения.
Когда речь идёт о UI (end-to-end) или API (функциональные) тестах, то всё кроме селениума и подобных библиотек — ненужная лажа для автоматизации тестирования, которую пытаются впарить клиентам за баснословные деньги. Пришлось прочувствовать это на своём опыте, когда CTO назначил использовать пару подобных платных штук (хиптест и что-то ещё, уже не помню название), вместо nunit\xunit и ЯП. Через год мучений просто отказались и забыли как страшный сон. Ускорение выполнения только после переделки под nunit выросла в 3 раза.
Вся автоматизация должна делаться исключительно на языке программирования, дабы минимизировать стоимость поддержки, скорость запуска и разработки, а также покрывать условия:
1. На каждый тест легко создаётся свой набор данных и легко удаляется. Система должна оставаться чистой
Например в базе данных перед и после должно удаляться всё что, касается ордеров, если мы тестируем фильтры или создание\отображение ордеров. И потом создаваться нужные наборы и комбинации, а не из кучи мусора выбирать нужный нам.
2. Должен быть максимально гибкий и удобный инструмент по созданию тестовых данных.
Очевидно что это код на ЯП, а не галиматья в виде скриптов от третьесортных систем, кукумберов и прочей визуальной фигни. И не да бог с кодогенерацией.
Никакие апи или там SQL скрипты также не подходят для создания тестовых данных.
а) Апи (речь про открытые интерфейсы, не про библиотеки) или веб-апи не подходит потому, что ваша система может тупо не иметь апи для создания половины сущностей. Например вы тестируете грид и фильтры (достаточно просто насоздавать разных ордеров), а ордера импортируются кучей разных сервисов из разных маркетплейсов. Т.к. тест должен иметь ограниченный контекст и не занимать пол дня, то разумно отображение тестировать отдельно, а импорт сервисов — отдельно, т.к. это другая система из другого сценария. Конечно же может быть и сценарий по импорту ордеров из маркетплейса. Но его набор данных не должен быть связан с тестами фильтра на гриде.
б) Чистые SQL скрипты создания данных не подходят потому что поддержка их будет заниматься больше времени, чем создание теста, а всё на стороне БД будет изменяться очень-очень часто. Вовремя отказались от такого, казалось бы, разумного подхода. Плюс скрипты в духе вставить в одну-две таблицы — это детский сад. В крупных системах такого не будет, а будет куча хранимок, иногда с несколькими версиями в которых сложно разобраться
Выход на самом деле простой — использовать DAL библиотеку, которую поддерживают разработчики для создания тестовых данных. Тогда вы изолируетесь от всего головняка с поддержкой своего самописного дала и от сложности создания многих сущностей в бд.
Ещё лучше, если у вас нормальные разработчики, использующие DDD там будет всё намного проще. Просто берёте фабрики с репозиториями и генерируете данные, которые вам нужны для UI\API
В автоматизации решает стоимость её поддержки. Автоматизация загибается, когда сложность поддержки увеличивается. При этом нужна достаточная гибкость при создании данных, а также скорость выполнения тестов. 200-300 end-to-end тестов выполняются 3-4 часа на UI. Против 20-30 минут для функциональных (АПИ), против нескольких минут для интеграционных (dal, связки систем), против нескольких секунд для unit (методы)
Скорость и покрытие напрямую зависят от способа создания данных. Если вам нужно протестировать 10 фильтров на гриде с кучей комбинацией, то что проще: каждый раз вызвать апи, создавая сущности или одним махом залить все нужные комбинации в базу, очищая все лишние сущности от прошлых тестов?
Вывод — ознакомьтесь с очередной подборкой «топ-5 самых лучших инструментов в year_number» и отложите их на полку, если они не могут быть использованы в коде.
Когда речь идёт о UI (end-to-end) или API (функциональные) тестах, то всё кроме селениума и подобных библиотек — ненужная лажа для автоматизации тестирования, которую пытаются впарить клиентам за баснословные деньги. Пришлось прочувствовать это на своём опыте, когда CTO назначил использовать пару подобных платных штук (хиптест и что-то ещё, уже не помню название), вместо nunit\xunit и ЯП. Через год мучений просто отказались и забыли как страшный сон. Ускорение выполнения только после переделки под nunit выросла в 3 раза.
Вся автоматизация должна делаться исключительно на языке программирования, дабы минимизировать стоимость поддержки, скорость запуска и разработки, а также покрывать условия:
1. На каждый тест легко создаётся свой набор данных и легко удаляется. Система должна оставаться чистой
Например в базе данных перед и после должно удаляться всё что, касается ордеров, если мы тестируем фильтры или создание\отображение ордеров. И потом создаваться нужные наборы и комбинации, а не из кучи мусора выбирать нужный нам.
2. Должен быть максимально гибкий и удобный инструмент по созданию тестовых данных.
Очевидно что это код на ЯП, а не галиматья в виде скриптов от третьесортных систем, кукумберов и прочей визуальной фигни. И не да бог с кодогенерацией.
Никакие апи или там SQL скрипты также не подходят для создания тестовых данных.
а) Апи (речь про открытые интерфейсы, не про библиотеки) или веб-апи не подходит потому, что ваша система может тупо не иметь апи для создания половины сущностей. Например вы тестируете грид и фильтры (достаточно просто насоздавать разных ордеров), а ордера импортируются кучей разных сервисов из разных маркетплейсов. Т.к. тест должен иметь ограниченный контекст и не занимать пол дня, то разумно отображение тестировать отдельно, а импорт сервисов — отдельно, т.к. это другая система из другого сценария. Конечно же может быть и сценарий по импорту ордеров из маркетплейса. Но его набор данных не должен быть связан с тестами фильтра на гриде.
б) Чистые SQL скрипты создания данных не подходят потому что поддержка их будет заниматься больше времени, чем создание теста, а всё на стороне БД будет изменяться очень-очень часто. Вовремя отказались от такого, казалось бы, разумного подхода. Плюс скрипты в духе вставить в одну-две таблицы — это детский сад. В крупных системах такого не будет, а будет куча хранимок, иногда с несколькими версиями в которых сложно разобраться
Выход на самом деле простой — использовать DAL библиотеку, которую поддерживают разработчики для создания тестовых данных. Тогда вы изолируетесь от всего головняка с поддержкой своего самописного дала и от сложности создания многих сущностей в бд.
Ещё лучше, если у вас нормальные разработчики, использующие DDD там будет всё намного проще. Просто берёте фабрики с репозиториями и генерируете данные, которые вам нужны для UI\API
В автоматизации решает стоимость её поддержки. Автоматизация загибается, когда сложность поддержки увеличивается. При этом нужна достаточная гибкость при создании данных, а также скорость выполнения тестов. 200-300 end-to-end тестов выполняются 3-4 часа на UI. Против 20-30 минут для функциональных (АПИ), против нескольких минут для интеграционных (dal, связки систем), против нескольких секунд для unit (методы)
Скорость и покрытие напрямую зависят от способа создания данных. Если вам нужно протестировать 10 фильтров на гриде с кучей комбинацией, то что проще: каждый раз вызвать апи, создавая сущности или одним махом залить все нужные комбинации в базу, очищая все лишние сущности от прошлых тестов?
Вывод — ознакомьтесь с очередной подборкой «топ-5 самых лучших инструментов в year_number» и отложите их на полку, если они не могут быть использованы в коде.
Sign up to leave a comment.
10 лучших инструментов для автоматизации тестирования ПО