Сложное тестовое окружение
Под сложным тестовым окружением я понимаю ситуацию когда у тестируемых объектов сложная история . Под историей подразумеваю последовательность операций, которые приводят базу и объекты в ней в нужное тестовое состояние. Тестируемый объект - это уникальный объект тестируемой системы, как правило элемент справочника, обладающий уникальными свойствами, с точки зрения предметной области. Это еще означает, что в типовых конфигурациях большое количество бизнес-логики, которая контролирует операции с данными объектами.
Самыми яркими примерами таких объектов является основное средство и сотрудник. Например, невозможно несколько раз принять к учету одно основное средство.
Чтобы протестировать продажу основного средства нужно как минимум выполнить следующие операции:
- создать элемент справочника номенклатура или объекты строительства,
- провести документы закупки,
- создать элемент справочника основные средства,
- провести документ принятие к учету основного средства,
- начисли амортизацию.
Для более сложного тестового примера, потребуется провести модернизацию, перемещение или другие подобные операции, изменяющие состояние и параметры основного средства.
Для тестирования функционала зарплаты, потребуется создать элементы справочников физические лица и сотрудники, провести документ принятия сотрудника на работу.
Возникает вопрос, как сформировать нужное тестовое окружение и состояние для подобных тестовых объектов. В этой заметке рекомендовал в общем случае использовать подход с созданием окружения при запуске каждого теста. В таком случае получаем большой объем подготовительной работы, которая резко увеличивает длительность выполнения тестового сценария.
Допустим есть следующие сценарии и в каждом сценарии будет создаваться уникальное тестовое окружение:
- списание ос после модернизации
- продажа ос после модернизации
- амортизация ос после модернизации
- амортизация ос после списания ос
- амортизация ос после продажи ос
При этом нужно либо дублировать алгоритмы создания окружения, либо выносить все в отдельный сценарий и вызывать с параметрами, но в любом случае получаем большое количество однотипных повторяющихся операций. Побочный эффект такого подхода, это в случае ошибки при создании окружения, не получается выполнить сам сценарий и проверить работу тестируемых объектов.
Получается, что более эффективным подходом является создание глобального окружения. Таким образом нужно один раз, при подготовке начальной тестовой базы, создать несколько вариантов окружения и использовать объекты в сценариях. Побочный эффект такого подхода, это необходимость отменять проведение документов, сформированных в сценарии, чтобы не нарушать исходное состояние созданного окружения.
Преимуществом такого подхода является то, что мы тестируем только те объекты, которые нужно и не тестируем лишнее. В результате тесты проходят быстрее и меньше ломаются, т.к. в сценарии задействовано мало объектов.
К недостаткам можно отнести усложнение понимания кода сценария, т.к. в нем нет информации об используемом окружении. Можно решить с помощью комментария. Хрупкость окружения, т.к. к базе есть доступ пользователей, то состояние тестового окружения может быть нарушено.