Здравствуйте!

Есть достаточно большой проект (на python) без unit test'ов. Планируем для новой функциональности, для новых фичь писать unit test'ы. Так как опыта в написании unit test'ов мало, ну и в общем больше знаю теории чем практики, меня очень интересуют best practices, то есть лучшие способы применения, которые бы поспособствовали тому, чтобы unit test'ы действительно стали хорошим инструментом в разработке нашего проекта. Хочу написать свои мысли о unit testing'e, которыё сформировались по ходу изучения этого вопроса... Да и вопросов осталось очень много...

1) в книге "The art of unit testing" прочитал, что 20% покрытие кода тестами — это слишком мало, тоесть плохо. А какой процент можно считать хорошим?
В общем, у меня сформировалось наверное достаточно идеалистическое убеждение в том, что лучший результат достигается, если покрывать 100% кода. Конечно на практике вряд ли это возможно. Хотя бы потому, что нету смысла тестировать простые get/set методы ну и тому подобное. Но всё же мне кажется, что очень важно покрывать как можно больше, иначе unit testing, как инструмент, будет терять свои качества. И вот интересный вопрос. С уменьшением показателя code coverage эффективность unit test'инга падает линейно или экспоненциально? Мне кажется, что экспоненциально. Это верно?

2) верным ли будет то, что даже если процентный показатель покрытия остается не таким и большим, ну, например 50%, — это тоже намного лучше чем ничего? Или все же с таким показателем вернее будет сказать: лучше ничего чем такой невысокий показатель?

3) кроме всего прочего разрабатываем web-приложение. Собираемся покрывать unit test'ами контроллеры. Как вы думаете, могут ли unit test'ы послужить хорошей службой, если тестировать только главные методы (входные точки, public методы) контроллеров? Или все же важно тестировать так же и всё, что находится за кулисами, даже если там тривиальный код? Или всё тривиальное (private методы и тому подобное) можно спокойно пропускать? (простые get/set методы поскольку понимаю можно пропускать, но что если взять, что-то чюточку сложнее?)

4) у меня сформировалось убеждение, что самая лучшая практика написания unit test'ов состоит в том, чтобы писать только один assert в одном unit test методе. Даже если в тестируемом методе последовательно находятся, например, три разных вызова:

foo()
bar()
baz()

, то лучше всего написать три отдельных unit test'а, каждый из которых подтвердит каждый вызов. Верно ли это?

5) Сложилось впечатление, что если писать не по TDD, это плохо сказывается на качестве unit test'ов. Или это совсем не важно пишутся ли unit test'ы по TDD или нет?

6) Насколько я понял, перед тем как командой писать unit test'ы очень важно сформулировать подробный и четкий список соглашений по котором будут писаться unit test'ы. Например, там будут описаны соглашения о именах методов, классов, о том, что нельзя писать больше одного assert'а в рамках одного unit test метода и тому подобное. Наверняка ваша команда пользуется подобными соглашениями, или это не верно? Иначе, если писать unit test'ы без соглашений, то их будет трудно поддерживать разными разработчиками.

7) На какие грабли можно натолкнуться в нашем случае, когда мы только-только приступаем к практике unit test'ов?

8) Какие best practices? Что посоветуете?


Буду очень благодарен за любые заметки, комментарии, пожелания!



Спасибо!