Метрики тестов придумал

[singalen]

Количество классов, инстанцируемых тестом, и среднее число строк кода в них.
Хорошо покажет, где лишняя связность.

И ещё одна метрика наверняка будет очень полезной. Сейчас ведь можно ходить по синтаксическому дереву вызываемой функции/класса. Почему бы тесту не отследить значения, вычисляемые в вызываемой функции, и не посчитать, на какой % их написаны ассерты?

Задача сложная, но вполне выполнимая, даже одним человеко-программистом.
А метрика получится очень объективная и полезная. Вот мы и узнаем, что кто-то ассертит 60% вычислений, а кто-то - 3%.

Comments

[catty-ua.livejournal.com]

Хм, я думала какой-нибудь NCover уже давно делает что-то подобное..не ? Ну мож не всё, но что-то из этого ?

[singalen]

Фиг там. Максимум, что они проверяют - conditional/loop coverage.
Мне кажется, померять покрытие ассертами вообще никому в голову не приходило.

[catty-ua.livejournal.com]

А, ну я так и думала..)

[singalen]

Поправочка. По словам assertion coverage гуглится пара тулзовин для каких-то экзотических платформ. Хи-хи.
Кто хочет влипнуть войти в историю?

[singalen]

Выигрыш чего?

Второе - это просто более точная метрика, которую должен показать CI. Точнее бранча, как бранч точнее лайн-кавераджа.

Первое - чётко будет заставлять людей разбираться со связностью. И это почти всегда хорошо.

[singalen]

По первой - от 3/50 до 200/5000. Что очень показательно.
По второй - примерно на половину-треть меньше, чем бранч каверадж.
По-моему, вполне информативно.

[profuel.livejournal.com]

первая метрика действительно интересно звучит, но я пока не до конца понял ее границы и еобходимость ее улучшения.
А вот со второй - очень спорные мысли:
1 - будет заставлять ассертить все подряд
2 - не факт, что при 90% покрытии вычислений ассертами, будет гарантирована правильность вычислений.
Скорее всего, принуждать к асертам надо будет в тех местах, где проверяемый результат получен с некоторой степенью сложности (функция с более чем 5 строками, например).

[singalen]

И правда, начнут ассертить всякое говно.
Тогда подумаем о немного другой метрике - покрытие ассертами:
а) всех ветвей результата функции
б) всех ветвей сайд-эффектов функции.

[profuel.livejournal.com]

да-да, об этом и пытался намекнуть добавив некий порог для проверяемых функций.
А на счет сайд эффекта, по-моему, перебор, хотя бы с точки зрения программирования этой метрики :)
Ведь проверяя некую переменную после вызова функции, которую она "вроде бы может" поменять - будет ну совсем непонятно при чтении теста коллегой.

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

[singalen]

Ну, да, про сайд-эффекты - это очень сложная тема. Но идея всё равно кажется перспективной.


> разве сейчас не так?

Сейчас, вообще-то, вообще никак. Не видел ни одной тулзы для мейнстрима, которая проверяет покрытие ассертами.
Есть шанс стать первым :D

[profuel.livejournal.com]

точно. я спутал в голове покрытие и покрытие ассертами.
Осталось попробовать написать это :)
Судя по всему, с дотНета будет проще начать, а потом уже и для Джавы подтянуть

[singalen]

"А по-моему, они одинаковые!"

[profuel.livejournal.com]

ты о покрытиях? если да, то нет :)

[singalen]

Не, я о C# и Java.

[profuel.livejournal.com]

тогда не знаю :)
без понятия, как следить за выполнением строк кода :)

[singalen]

Только статическим анализом, я полагаю.

[profuel.livejournal.com]

Как минимум можно каждым ассертом проверять путь "наверх" по стеку вызова и помечать выполненные строки, а потом сравнить это количество с общим.

[singalen]

Вернее, запоминать каверадж конкретно вызовов, вычисляющих expected value. В самом-то стеке ассерта ничего интересного нет.

[profuel.livejournal.com]

да-да, говоря "ассертом" - имел в виду внутренним кодом функции.