"Правильный" тестовый фреймворк
Несколько мыслей о том, каким должен быть "правильный" тестовый фреймворк.
По моему мнению, степень правильности определяется исходя из требований и задач, которые должен будет выполнять фреймворк. К примеру, если на проекте есть и веб-сервисы и UI часть, то при написании фреймворка для UI тестирования следовало бы изначально закладывать возможность создавать предусловия для тестов используя веб-серввисы. Если же возможности такой нету, то просто делайте архитектуру для UI тестирования. Чаще всего начинающие автоматизаторы совершают большую ошибку - делаем, как получается, а потом будем рефакторить. Зачастую это самое "потом" не наступает. Но все же давайте мыслить структурировано: фреймворк должен быть модульным. Если вы пишите фреймворк на объектно-ориентированном языке ( Java,C#,Python ), то вы обязаны выделять функциональности и "отделять мух от котлет". В противном случае будет "макаронный код", а к нему в придачу большие затраты на поддержку тестов и всей инфраструктуры. Модульный фреймворк можно сравнить с конструктором лего.
Когда есть такие маленкие блоки, как PageObject, DataProvider,DAO, BaseTest class, собрать из этого всего фреймворк может даже джуниор, который пришел к вам на проект пару недель назад. Еще одно преимущество модульности в том, что вы легко можете заменить один элемент на другой, поменяв реализацию либо инструмент. Модульность дает вам гораздо больший радиус поворота. Скажем, когда у вас на проекте 15 - 20 тестовых сценариев, то вы можете не задумываясь в них ковыряться и тратить по 15-20 минут в день на поддержку, а вот когда их становится 1500-2000, то тут начинаются пляски с бубном, сопли и визги: "какой же хреновый у нас фреймворк, че ж мы раньше-то не делали хорошо, сейчас уже поздно…" Так вот, чтобы избежать такой ситуации, мой вам совет перед началом разработки фреймворка: подумайте, выделите основные части, запрограммируйте их в виде модулей, напишите пару тестов на конкретные функциональности, поэкспериментируйте, найдите свой рецепт успеха. Лично мой опыт показывает, что модульный фреймворк выигрывает у "макаронного кода" по всем параметрам.