Плюс, результат роботи coverage, ще може слугувати тільки індикатором того, що кількісні показники тестів падають, а не кількісним показником.

Ну остання проблема з coverage - він погано працює з мультипроцесингом в nose 0.11 ))

Отже, я підвожу до думки, що coverage не повинен використовуватися як якісний чи кількісний показник - ми його можемо використовувати виключно як індикатор - закомітили новий код, coverage суттєво впав - значить новий код погано тестується.

Яким же чином перевіряти що код нормально протестований? В нас поки це робиться виключно вручну, і, відповіно, маємо проколи, коли пропускаємо погано тестований код, особливо коли працюємо на передодні дедлайну, і кожна хвилина на вагу золота.

Мені видається, можливим рішенням такої проблеми буде написання невеличкого синтаксичного аналізатора, який перевірятиме пітонівський код таким чином:

• матиме власну базу даних, яка міститиме інформацію про класи, функції, змінні, etc стандартної бібліотеки та найбільш вживаних бібліотек
• аналізуватиме код, для кожного з елементів коду фіксуватиме набір тестів, які його викликають
• при знаходження викликів будь чого зі своєї бази в коді, братиме з бази набір тестів, які повинні бути застосовані до цього коду, та звірятиме їх з тими тестами, які фактично існують
• видаватиме звіт

Як цей аналізатор має працювати в реалі:

• знаходить у коді виклик urllib.urlopen
• знаходить у своїй базі, що такий виклик повинен перевіряти - помилки 403, 404, 500
• звіряє з тими тестами, які викликають цей шматок коду
• якщо не знаходить у цих тестах моків urllib.urlopen на всі три помилки, видає в звіті помилку на те, яка помилка не замокана

Отже, я поки думаю, як такий аналізатор написати.

Може підкажете мені, чи існує щось подібне, чи, можливо, я заїхав зовсім не в ту сторону?