Писать ли Unit-тесты до готовности MVP?

Question

[JuVer]

Писать ли Unit-тесты до готовности MVP (минимально жизнеспособного продукта)? Какие у вас есть аргументы ЗА и ПРОТИВ, поделитесь пожалуйста опытом.
— Команда, в которой практически нет опыта написания модульных тестов и которая перешла на scrum.

Comments

[Максим Федоров]

ЗА: с юнит-тестами вы пишите простой надежный код, и потому — хотя бы на важный код и основную бизнесуху стоит писать тесты. Тесты помогают отследить многие рантайм-ошибки и по сути помогают вам, потому тесты точно стоит делать с динамическими языками (PHP, Ruby, Python).

ПРОТИВ: если упарываться на покрытии, то они могут мешать, отнимать время и делать некоторые ожидания ложными. Больше недостатков нет.

[Mpyrulearn]

Максим Федоров, главный недостаток - двойная работа, не только код писать но и тесты. имхо.
Когда есть огромный штат разработчиков, там понятно - можно выделить людей на это.
А если 1-2 человека занимаются кодерством = какой смысл вообще в тестах?
Когда и так помнишь какой код за что отвечает и как работает. (в небольших проектах)

[Максим Федоров]

Mpyrulearn,
не помнишь, — да и зачем помнить то, что не нужно
не двойная работа: улучшение кода и делать его проще — для одного также важно, как и для 10-х, работал в одного и преуспел очень в том, что код стал прост и после меня его легко поддерживали, но тк тесты мешались — наговнили со временем (facepalm)

там понятно - можно выделить людей на это

на что "на это"? Свой код покрывается тестами только вами!!! Иначе вы говна напишите, потом говном и покроют

[Mpyrulearn]

Максим Федоров,

улучшение кода и делать его проще — для одного также важно, как и для 10-х, работал в одного и преуспел очень в том, что код стал прост и после меня его легко поддерживали

ну для себя я не вижу смысла постоянно переписывать старый код.
Работает? выполняет нужные задачи? Ошибок нет? время работы приемлимое?
- "Работает - не трогай!" (с)

p.s. но и опыта работы в компании с другими программистами у меня пока нет(

[Максим Федоров]

Mpyrulearn, я не знаю, сколько вы пишите кода, но при ИЗМЕНЕНИИ своего же кода я не могу гарантировать, что ВСЕ работает также просто потому что я так думаю — я точно знаю, что я ошибаюсь и забыл примерно так с 3-4 десятка моментов...

ну для себя я не вижу смысла постоянно переписывать старый код.

я тоже, но и речь не об этом

более того — я не могу гарантировать, что текущий код работает точно по тем кейсам, которые я подразумевал при написании, уж слишком мой мозг прост и маловместителен и когнитивнонеустойчивый... кстати не встречал очень вместительных умов еще ни разу, вы скорее всего первый из таких (нет)

Answer 1

[jazzus]

Дело не только в поддержке кода. С тестами, если писать их до фичи, имхо самая продуктивная и быстрая разработка.
Во-первых это детальное тз. А любое тз ускоряет процесс.
Во-вторых не нужно шлепать браузером при кажом чихе. Заполнять формы руками и т.д. Плюс если несколько ролей доступа или связанные процессы, то руками проверять геморой.
В третьих поддерживает код в дальнейшем, незаменим при рефакторинге и является отличной документацией. Нужно вспомнить процесс и какая логика - печатаешь тест на принтере и вспоминаешь под кофеек. Короче рекомендую.

Comments

[Aлександр]

Для того чтобы не заполнять формы руками есть coded ui тесты. На пример Selenium и т.д

[jazzus]

Aлександр, это не про ui. Проверка бэка исключительно. Формы как реквест. Валидация, права доступа, логика - у меня на бэке все начинает работать/тестируется, когда фронта еще в задумках нет))

Answer 2

[ArthurAm]

Напишите смоук тесты на критичные места и хватит. А то получится как например в этой статье , где человек 4 месяца выстраивал архитектуру с нулевым опытом в проектировании и писал тесты по три недели на модуль, вместо того чтобы выкатывать MVP

Comments

[jazzus]

какие 3 недели.. к какому-нибудь модулю типа комментариев фича-тест из 1000 строк пишется за час-полтора. Однотипные действия типа

$this->postJson(route('articles.comments.store', $article), $comment)
     ->assertCreated()
     ->assertJsonMissingValidationErrors();

клепаются один за другим. Сэкономит потом кучу времени, особенно когда нужно проверить разные права доступа в зависимости от логики. Руками такое просто не проверить.