#программирование #тестирование #python

@russian_mastodon @rf

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

Ну то есть реально. Вот есть у нас набор классов и их методов. Что конкретно нужно покрыть тестами? Только то, что подразумевает пользовательский ввод данных? Или вообще все мыслимые ситуации? Тогда код тестов может легко раз в 10 превысить основной код программы. И в чем тогда смысл существования тестеров, как отдельной функции на проекте?

Мне пока хотя бы общие моменты какие-то, без тонкостей и специфики разных ситуаций.

PS: да, @hardworm , у меня есть та книга, которую мне скидывал, но я пока не готов ее осилить - я даже основ не понял еще.

@cauf Если ну очень сильно упрощать:
* Пишешь тест с желаемым поведением метода до его кода, например, add(2, 3) должен вернуть 5;
* Так как кода ещё нет - тест должен сломаться;
* Пишешь код, который любой ценой удовлетворяет тесту;
* Тест должен починиться, рефакторь то что написал;
* Добавь кейс где ты меняешь ввод и ожидаемый результат, тест обязан сломатся;
* Чинишь метод чтобы он удовлетворял уже двум кейсам;
* Рефакторишь код между починкой теста и вводом нового кейса;
* Повторить;

Follow

@cauf Суть тестов в том, что ты предусматриваешь различные ситуации поведения твоего метода так, чтобы он с ними справлялся или, хотя бы, не взрывался если от него просят то что он неспособен сделать. В будущем ты будешь уверенно знать, что этот метод надежен и делает то что нужно, благодаря его успешным тестам.

Если тест способен сломаться от введения новых условий которые метод ещё не умеет решать и/или изменения логики существующего кода (не рефакторинга) - это хороший тест.

@toby3d Отлично объяснил. Спасибо большое!

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!