Я только начал изучать проект, который имеет> 20 тыс. Модульных тестов, написанных на Rspec (сам проект написан не на Ruby; только тестовые случаи). Ожидается, что в будущем число тестовых случаев значительно возрастет, поскольку будет добавлено больше функциональных возможностей. То, что уже произошло (в течение длительного периода), - это то, что RSpec изначально был особенно хорошим решением для тестирования этого проекта, но по мере роста проекта довольно специальная структура их тестовых случаев RSpec сильно их укусила. Одна из самых больших проблем, с которыми они сталкиваются, связана с таксономией в их тестовом коде - структурой (или отсутствием) в именовании их тестовых примеров, приборов, вспомогательного кода и т. Д. В их тестовых случаях.
Как вы можете себе представить, с> 20k модульными тестами существует много методов с очень похожими именами, использующих вспомогательные методы, которые все загружаются из глобального пространства имен.
Чтобы выделить только одну область, где проблема кусается, в этом приложении ~ 10 баз данных. Проверка структуры таблиц / столбцов / представлений / ограничений / хранимых процедур / ... для всех этих баз данных - это то, что (вполне разумно) рассматривается в рамках существующих модульных тестов RSpec. Однако общее число объектов DDL в этой коллекции баз данных, которые необходимо проверить, вероятно, составляет> 10000; Для охвата всего диапазона структурных проверок БД и для возможности выборочного тестирования только подмножеств структуры БД требуется:
10000 отдельных методов (и я сразу исключаю этот вариант!)
- довольно сложное соглашение об именах в тестовых примерах (то есть что-то, включающее имя БД + имя таблицы + имя столбца + ...),
- ИЛИ прохождение, например Имя БД, имя таблицы, имя столбца, ... для универсального метода
- ИЛИ разделение интересов через пространства имен (и я не знаю, как изящно масштабируемый способ сделать это в RSpec),
- ИЛИ какое-нибудь умное метапрограммирование (которое, как я подозреваю, в конечном итоге может усложнить и без того грязную структуру).
То, что существует сейчас, - это, насколько я могу судить, немного всего вышеперечисленного, с не очень очевидным планированием ...
Есть ли у вас какие-либо советы или рекомендации, на которые я мог бы обратить внимание, чтобы попытаться исправить этот беспорядок и дать им какую-то масштабируемую структуру для их тестирования RSpec? В частности, приветствуются предложения по структурированию различных файлов RSpec для очень больших проектов.