Я управляю тестированием очень крупной финансовой системы ценообразования. Недавно наш штаб настаивал на том, чтобы мы убедились, что каждая часть нашего проекта имеет значимый тест на месте. По крайней мере, им нужна система, которая гарантирует, что когда мы что-то изменяем, мы можем обнаружить непреднамеренные изменения в других подсистемах. Предпочтительно они хотят что-то, что подтверждает правильность каждого компонента в нашей системе.

Это, очевидно, будет довольно много работы! Это может занять годы, но для такого рода проекта оно того стоит.

Мне нужно выяснить, какие части нашего кода не охвачены ни одним из наших юнит-тестов. Если бы я знал, какие части моей системы не тестировались, я мог бы приступить к разработке новых тестов, которые в конечном итоге приблизились бы к моей цели полного охвата тестированием.

Итак, как я могу провести такой анализ. Какие инструменты доступны для меня?

Я использую Python 2.4 на Windows 32bit XP

UPDATE0:

Просто чтобы уточнить: у нас есть очень полный набор модульных тестов (плюс отдельный и очень полный набор тестов, который выходит за рамки этого упражнения). У нас также есть очень стабильная платформа непрерывной интеграции (созданная с помощью Hudson), которая предназначена для разделения и выполнения стандартных юнит-тестов python на нашем испытательном стенде: около 20 ПК, созданных по спецификации компании.

Цель этого упражнения - устранить пробелы в нашем наборе юнит-тестов python (только), чтобы каждый компонент имел некоторую степень покрытия юнит-тестами. Другие разработчики будут нести ответственность за не-Python-компоненты проекта (которые также находятся за пределами области видимости).

& Quot;Component& Quot; намеренно расплывчато: когда-нибудь это будет класс, в другой раз - целый модуль или сборка модулей. Это может даже относиться к единой финансовой концепции (например, к одному типу финансового опциона или финансовой модели, используемой многими типами опционов). Этот торт можно разрезать разными способами.

& Quot;Meaningful& Quot; Тесты (для меня) - это те, которые подтверждают, что функция делает то, что изначально задумал разработчик. Мы не хотим просто воспроизводить регестии на чистом питоне. Часто намерение разработчика не является сразу очевидным, поэтому возникает необходимость исследовать и прояснять все, что выглядит неопределенным, а затем закрепить это знание в модульном тесте, который делает первоначальное намерение довольно явным.