И сколько вы реальных ошибок смогли найти используя тесты(ну т.е. ошибки которые бы прошли все остальные стадии проверки, но нашлись только юнит-тестированием)
Ну я не стану врать, что мои юнит-тесты постоянно находят ошибки, которые иначе никак не заметить, и которые уходят в продакшен. Повторюсь, пост основан на моем опыте. Я не утверждаю, что это все верно и для вашего.
А в моем же случае написать юнит-тест на новый кусок кода не занимает больше 10-15 минут. В моем личном опыте написание тестов более чем оправдано. Иногда бывает, что добавление функциональности в одном месте ведет к ошибкам в другом, и тесты ловят такой регресс.
> Осталось только подсчитать, программист больше времени потратит на починку багов или на написание тестов?
Я не знаю специфику вашей работы, но в моем опыте написать юнит тест – это лишние 10 минут. А отправка кода в тестирование, возвращение на доработку, анализ логов и повторный вход в контекст – побольше.
В любом случае, мы сейчас обсуждаем ситуации в вакууме. В каждом конкретном случае надо делать взвешенные решения исходя из ситуации.
Кто-то с первого же абзаца понял, что это это ирония. Другие даже к концу поста не понимают, и это нормально. Но все же, если вы ко всему этому относитесь так серьезно, то вам определенно стоит проще смотреть на мир.
> У меня было много задач, которые состояли почти целиком из интеграции разных систем. Тесты в таком случае получаются почти полностью состоящими из моков и т.п., и ну вот нифига никакие баги реальные не ловят.
Вот это кстати очень хорошо объясняет мне вашу позицию. Я согласен, что тестировать моки не имеет смысла. В моем же опыте сами модули довольно крупные, и в них юнит-тесты вписываются замечательно с минимумом моков.
> Отрефакторили. Бац — а все уже совсем хорошо.
А бывает, что отрефакторили – и что-то не то. Тесты такое отловят :)
На самом деле, я думаю, что мы говорим об одном и том же, но с разных ракурсов.
Я, конечно, не в курсе тонкостей вашей работы. Но если вы работаете в компании, то пришедший после вас разработчик может в этом всем не разобраться.
Грань тонка. Если вы работаете на результат и обеспечиваете его, то это здорово. Но разработка ПО – это сложный процесс, и основной его жизненный цикл проходит в сопровождении, а не написании. Я бы предполжил, что вам неплохо было бы добавить еще человека, чтобы вам вместе было проще проводить необходимый комплекс работ, но, как я уже упомянул, я не в курсе тонкостей вашей работы.
> Всегда думайте своей головой. Не делайте чего-либо по инерции, просто потому, что все говорят так делать.
Но все-таки моя голова говорит, что после меня должен не просто остаться код, который как-то, но работает, но принявший его человек должен быть в состоянии его поддерживать и понимать. Тут уже важен баланс.
> выбрать язык с более строгой статической системой типов, который не даст написать некоторые вещи неправильно
Поверьте, это не особо поможет) Статическая система типов не беспокоится о вашей бизнес-логике.
Насчет дороговизны отсутствия тестов – нет, не измерял, вот честно. Но мне лично это кажется очевидным.
Кейс:
1. Разработчик пишет код без тестов. Запускает локально проект, вроде норм. Отдает тестировщикам
2. Тестировщики находят баги, возвращают
3. Разработчик продолжает ковыряться и получать зарплату
Вместо этого можно написать тесты, и тогда тестировщики не вернут задачу на доработку.
Это все условно, конечно. Ситуации в вакууме. Я согласен, что есть грань, и нужно преследовать не какие-то конкретные цифры в покрытии, а просто делать хорошо.
Я бы сказал, что основная цель любого занятия – сделать хорошо. Сделать так, чтобы результатом твоей работы могли пользоваться другие и получать от этого пользу. Это и есть качественно выполненная работа. Тесты помогают этого достичь, не более. Их может быть больше или меньше, просто надо всегда здраво оценивать ситуацию и работать не результат.
Вы описали идеальную картину мира, как по мне. Но на деле это, как и любые другие идеалы, недостижимо.
Для меня самым важным экономическим обоснованием написания тестов является то, что их отсутствие может стоить еще дороже. В первую очередь я говорю о регрессе. Когда проект хоть сколько-нибудь большой, то правки в одном месте могут привести к ошибкам в другом. И нет, дело вовсе не в отсутствии профессионализма, а в том, что просто все сразу в голове удержать не получается. Думаешь об одном, упускаешь другое. Для этого нужны тесты – чтобы вы не просто добавляли новые фичи, но при этом и не ломали бы старые.
Разумеется, ни пользователь, ни заказчик не скажут вам про важность тестов. Это не их компетенция, им просто нужен работоспособный продукт. А его работоспособность обеспечивают не только хорошие специалисты, но и хорошее тестирование (как QA, так и модульное).
Вы слишком толерантны. Подход, описанный в статье, не подойдет никому. Разумеется, если целью стоит грамотное развитие проекта.
Думаю, после прочтения заключения (под спойлером) вы лучше поймете цель этого поста, и все сразу встанет на свои места :)
Чукча не читатель – это точно, потому что кто-то не дочитал до заключения.
Но я вам больше скажу – happy path это чушь, вы должны ломать свой код в тестах. Меньше happy, больше хардкора.
Ну я не стану врать, что мои юнит-тесты постоянно находят ошибки, которые иначе никак не заметить, и которые уходят в продакшен. Повторюсь, пост основан на моем опыте. Я не утверждаю, что это все верно и для вашего.
А в моем же случае написать юнит-тест на новый кусок кода не занимает больше 10-15 минут. В моем личном опыте написание тестов более чем оправдано. Иногда бывает, что добавление функциональности в одном месте ведет к ошибкам в другом, и тесты ловят такой регресс.
> Но да, нужно уметь читать код, а не только названия функций.
Хочу только добавить, что чтобы уметь читать код, нужно прежде всего уметь его писать :)
> Осталось только подсчитать, программист больше времени потратит на починку багов или на написание тестов?
Я не знаю специфику вашей работы, но в моем опыте написать юнит тест – это лишние 10 минут. А отправка кода в тестирование, возвращение на доработку, анализ логов и повторный вход в контекст – побольше.
В любом случае, мы сейчас обсуждаем ситуации в вакууме. В каждом конкретном случае надо делать взвешенные решения исходя из ситуации.
Пост я писал из своего опыта – а это энтерпрайз с более-менее крупными модулями. Тут с тестами однозначно лучше, чем без них.
Вот это кстати очень хорошо объясняет мне вашу позицию. Я согласен, что тестировать моки не имеет смысла. В моем же опыте сами модули довольно крупные, и в них юнит-тесты вписываются замечательно с минимумом моков.
> Отрефакторили. Бац — а все уже совсем хорошо.
А бывает, что отрефакторили – и что-то не то. Тесты такое отловят :)
На самом деле, я думаю, что мы говорим об одном и том же, но с разных ракурсов.
Грань тонка. Если вы работаете на результат и обеспечиваете его, то это здорово. Но разработка ПО – это сложный процесс, и основной его жизненный цикл проходит в сопровождении, а не написании. Я бы предполжил, что вам неплохо было бы добавить еще человека, чтобы вам вместе было проще проводить необходимый комплекс работ, но, как я уже упомянул, я не в курсе тонкостей вашей работы.
> Всегда думайте своей головой. Не делайте чего-либо по инерции, просто потому, что все говорят так делать.
Но все-таки моя голова говорит, что после меня должен не просто остаться код, который как-то, но работает, но принявший его человек должен быть в состоянии его поддерживать и понимать. Тут уже важен баланс.
А я не могу. Языкам программирования нет дела до бизнес-логики приложения, а тестируют именно ее, а не базовые конструкции языка.
Поверьте, это не особо поможет) Статическая система типов не беспокоится о вашей бизнес-логике.
Насчет дороговизны отсутствия тестов – нет, не измерял, вот честно. Но мне лично это кажется очевидным.
Кейс:
1. Разработчик пишет код без тестов. Запускает локально проект, вроде норм. Отдает тестировщикам
2. Тестировщики находят баги, возвращают
3. Разработчик продолжает ковыряться и получать зарплату
Вместо этого можно написать тесты, и тогда тестировщики не вернут задачу на доработку.
Это все условно, конечно. Ситуации в вакууме. Я согласен, что есть грань, и нужно преследовать не какие-то конкретные цифры в покрытии, а просто делать хорошо.
Я бы сказал, что основная цель любого занятия – сделать хорошо. Сделать так, чтобы результатом твоей работы могли пользоваться другие и получать от этого пользу. Это и есть качественно выполненная работа. Тесты помогают этого достичь, не более. Их может быть больше или меньше, просто надо всегда здраво оценивать ситуацию и работать не результат.
Для меня самым важным экономическим обоснованием написания тестов является то, что их отсутствие может стоить еще дороже. В первую очередь я говорю о регрессе. Когда проект хоть сколько-нибудь большой, то правки в одном месте могут привести к ошибкам в другом. И нет, дело вовсе не в отсутствии профессионализма, а в том, что просто все сразу в голове удержать не получается. Думаешь об одном, упускаешь другое. Для этого нужны тесты – чтобы вы не просто добавляли новые фичи, но при этом и не ломали бы старые.
Разумеется, ни пользователь, ни заказчик не скажут вам про важность тестов. Это не их компетенция, им просто нужен работоспособный продукт. А его работоспособность обеспечивают не только хорошие специалисты, но и хорошее тестирование (как QA, так и модульное).
Думаю, после прочтения заключения (под спойлером) вы лучше поймете цель этого поста, и все сразу встанет на свои места :)
Но я вам больше скажу – happy path это чушь, вы должны ломать свой код в тестах. Меньше happy, больше хардкора.