Follow

@russian_mastodon @rf

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

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

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

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

· · Web · 11 · 3 · 2

@nrwka Спасибо! Вроде бы похоже на то, что мне нужно!

@cauf @russian_mastodon @rf @hardworm я думаю юнит-тестирование применяется больше в смок-тестах, в регрессе. Все возможные ситуации покрывать нет смысла. Нужно проверить что функция продолжает работать когда накатили новую поставку

@Dworkin @russian_mastodon @rf @hardworm
Блин... Я половину не понял, что ты написал. Но спасибо, что старался :)

@cauf Если не знаешь, что делать - делай то, что говорит начальник. Суть тут не в том, что начальник умный (обычно дурак), а в вкорячивании в код того, а чем ты никогда не думал, обычно блокчейн если это стартап или код на Коболе если это не стартап. Воот… Кстати, о тестах.. Если тест принудил тебя переписать код таким образом, что оказалось, что вкорячивать блокчейн легче, чем до написания теста - это был нужный тест. А потом задним умом можно понять, какие свойства сделали этот тест нужным.

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

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

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

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

@cauf
Крисмаса потыкай же. Он на тестах собаку съел.

@russian_mastodon @rf @hardworm

@radjah @russian_mastodon @rf @hardworm
не доверяю я этим собакоедам с кубани...

@radjah @cauf @russian_mastodon @rf тестировщики не имеют почти никакого отношения к unit тестам

@cauf @russian_mastodon @rf @hardworm

тестеры нужны для того чтобы находить новые тест-кейсы для юнит-тестов :)

@mva @cauf @russian_mastodon @rf @hardworm

Не только.
Вот например ты написал отличный код, он покрыт тестами на 100% и они отлично выполняются в CI. Но ты забыл какую-то важную мелкую деталь.
Тестер (который QA) может это обнаружить и вернуть тебе на доработку до того как ты обосрёшься перед заказчиком.

@cauf @russian_mastodon @rf там в той книге и есть основы. Если научился тестировать хотя бы сложение 2 чисел - читай. А то без основ можно бродить долго и не там

@hardworm @russian_mastodon @rf

Да мне пока некогда её читать. Надо тестовое задание делать и кучу всего по нему изучить. Вот хоть как-то тесты вписать надо

@cauf @russian_mastodon @rf @hardworm

1. Покрывать публичное API. Если чтобы протестировать класс нормально у тебя тянутся руки покрыть приватные методы - скорее всего что-то не так с классом.
2. В идеале покрыть все возможные IRL ситуации. Этого никогда не получится сделать, но стремиться надо.
3. Смысл тестеров в других видах тестирования, часто продукта в целом. Юнит-тесты, которые так же называют модульными тестами тестируют небольшие части твоего приложения и стараются обеспечить то, что каждый класс выполняет то, что он должен так как должен.

@skobkin @russian_mastodon @rf @hardworm

Спасибо, ты как всегда все по делу и кратко разъяснил

@cauf @russian_mastodon @rf @hardworm
По поводу пункта 2 дополню.

Абсолютно нормальная ситуация:

1. Обнаружил баг.
2. Пофиксил.
3. Написал новый тест, который будет проверять на этот баг и если он вдруг вернётся - тест будет флагом регрессии.

@skobkin @russian_mastodon @rf @hardworm
Мне кажется, это уже элементы регрессионного тестирования

@cauf @russian_mastodon @rf @hardworm
Регрессионное тестирование - это этакое мета-название всего, что обнаруживает регрессии.
И юнит-тесты вносят в него большой вклад.

@cauf ну вообще юнит-тесты логично писать параллельно с кодом, сразу проверяя, что то, что ты только что написал хотя бы работает так, как ты ожидаешь.
Если ты правишь готовый код без каких-либо тестов, то начать лучше всего с тех мест, где ты копаешься. Скажем, у тебя что-то падает, редьюсишь падение до минимального объёма кода, делаешь его тестом, а потом чинишь код, пока тест не пройдёт. Этакий локальный TDD.
А если тебе просто поставили задачу «покрыть вот этот кусок легаси-говна тестами», то я бы начал с тестирования обычного workflow, чтобы при следующих изменениях не ломали хотя бы основную функциональность приложения.

@rayslava Слава, спасибо за информацию!

@cauf @russian_mastodon @rf @hardworm
Попробуй в TDD. Перед тем как написать новый код - напиши падающий тест и потом "пофиксить" его. Потом жить без этого будет сложно :)

Sign in to participate in the conversation
Mastodon

lor.sh is yet another mastodon instance.