Регрессионное тестирование: Как доказать, что твой код не теряет данные

 · 2 min read

Собрать работающий прототип для себя довольно легко. Куда сложнее протолкнуть этот партизанский софт в официальные процессы огромной компании. Разработку базовой логики мы завершили, поэтому пришло время идти к руководству и защищать проект. Люди привыкли годами использовать старый генератор. Он собирал документацию часами, зато работал предсказуемо и позволял четко контролировать покрытие кода.

Преграда из недоверия

Сравнение архитектур: старый комбайн и новый движок

Наш движок использовал совсем другую архитектуру. Мы мечтали написать собственные легковесные парсеры. Жесткие сроки заставили взять готовый Doxygen, который работает медленно и почти не кэширует результаты. Зато он стабильно выдает XML. Наш код забирает этот формат, переваривает в свою модель данных и превращает в чистый Markdown.

Руководство отреагировало на такую многослойную конструкцию скептически. Нам задали прямой вопрос: где гарантии, что сторонний парсер не пропустит половину классов на нашем сложном C++? Обещания тут не работали. Требовались конкретные цифры.

Лобовое столкновение

Дашборд с показателями покрытия и процентом совпадений

Мы написали скрипт для регрессионного тестирования. Он напрямую сравнивал старый корпоративный стандарт и новый генератор Flude. Тесты прогонялись на 36 комбинациях SDK и языков программирования, включая C++, C# и Python.

Идея состояла в извлечении точного количества классов, методов и перечислений из старой документации. Затем мы сверяли эти числа с результатами нашего движка. Все данные сводились в единый дашборд. Мы смотрели на эталонные показатели, наши находки и итоговый процент совпадений. Там же висели списки потерянных сущностей и случайно прилипшего мусора.

Борьба с расхождениями

Вычищение служебного мусора из кода

Первые прогоны выдали тонны нестыковок. Выяснилось, что Doxygen давится сложными шаблонными конструкциями C++ и выдает пустые файлы вместо реального кода. В обертках для C# и Python наружу полезли внутренние классы автогенераторов, которые старый инструмент умел тихо скрывать.

Началась нудная рутина с написанием препроцессоров на лету. Мы вырезали проблемные куски кода еще до парсинга. Придумывали правила слияния для анонимных перечислений. Вычищали служебные хвосты. Каждая такая правка закрывала очередную дыру в метриках. Мы методично подгоняли результаты, пока процент совпадений не дополз до 99.9-100% для всех 36 комбинаций.

Контрольные цифры показали, что связка Flude и Doxygen находит те же десятки тысяч сущностей, что и старый стандарт. Никто нам сразу зеленый свет не дал. Мы просто доказали себе работоспособность концепции. Наша документация помимо справочников по API включает подробные руководства разработчика. О том, как мы интегрировали Developer Guides в новый генератор, расскажем в следующей статье.