Follow

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

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

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

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!