LINUX.ORG.RU

Что за такая практика (дурацая?) писать юнит тесты не автрам кода?

 , ,


1

1

Работаю удалённо, но в нашей небольшой компании юнит-тесты к своему коду пишет непосредственно разработчик кода.

Тем не менее после ухода из прошлой работы, остался доступ к их внутренним ресурсам. Иногда захожу почитать, и вот теперь прошлая комания модифицировалась в то что:

«ведущие"разработчики пишут код.

Менее эффективных разработчиков отправляют покрывать всё юнит-тестами.

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

Вернемся к теме того что авторы кода не пишут к нему тесты.

Разве это нормально? Очевидно же что именно автор кода может (и должен) подробно проверить свой собственный метод, класс, модуль, прежде чем переключить свой контекст своего мозга на дельнейшие задачи, ибо именно он лучше всех знает то что должно приходить на вход и выходить на выходе как правильный результат. Именно он знает что есть ошибка а что нет.

И если за него обнаружат баг а он уже делает n+1 задачу -будет дороже его пофиксать же.

Зачем привлекать к написанию тестов людей которые:

1. должны будут где-то узнать что должно входить (контракты), и что на выходе есть ок а что не ок (это им придется тратить время, а если документации нет (как правило) - то дергать автора кода, и тормозить его этим)

2. в некоторых случаях им придется создавать искусственно окружение для тестирования. А у автора оно по любому было на момент разработки.

Т.е. вижу только тормоза и вред для бизнеса если код тестируют не авторы, ибо детектинг багов и фиксинг будет происходить медленнее.

Или это как-то оправдано в компаниях где в приоритете время релизов а не качество продукта?

Объясните.



Последнее исправление: bober (всего исправлений: 1)

Это полная херня. Бывает, что тестов нет вообще, если нужно срочняк зашипить, но потом все равно догоняешь и покрываешь пост-фаткум (попутно находя 3+ позорных бага, которые не обнаружились, потому что наживо тестил руками happy path), но в нормальных условиях написал код - покрыл тестами, или вообще TDD. Когда юнит-тесты пишет кто-то другой, это, конечно, полезно, потому что они находят дисфункциональные моменты в API и т.д., но я не понимаю, как можно не писать И самому.

cdshines ★★★★★
()
Ответ на: комментарий от foror

переключать контексты с кода на тесты

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

cdshines ★★★★★
()

Представьте себе опен-сорс, в котором кто-то пишет тесты и создает ишшью, что «напишите тесты на PR #4634».

cdshines ★★★★★
()
Ответ на: комментарий от Iron_Bug

Одно другому не третье так-то. Практика показывает, что человек со стороны, пытаясь разобраться с тем как работает библиотека, может надыбать совершенно сказочных приколов которые разработчик не предполагал. Так что оставлять _все_ тесты на откуп разработчику тоже не очень идея.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

не, кроме юнит-тестов (это технический уровень), есть ещё QA-тестирование - это уже юзерско-прикладной уровень, так сказать. и они дополняют друг друга.

Iron_Bug ★★★★★
()

Как-то упустил тред на первой странице, ничего не читал, но подтверждаю. Тесты пишет НЕ ТОТ кто разрабатывает код, это ЗАКОН тестирования, это связенное правило, которое никто не смеет нарушать

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

К тому же, обязательно наличие так называемых детализированных requrements, они и должны быть общей точкой зрения разработчика и тестировщика в спорных местах. К тому же, тестировщик обязан выявлять места, которые можно трактовать двояко

I-Love-Microsoft ★★★★★
()

По-идее это логично. Разработчик подгонит тесты под себя,поэтому это объективней

protsquest
()
Ответ на: комментарий от Lordwind

Помнится тот джун, которого попросили хромого с опциями собрать под таргет, слился за пару часов. Не надо так с джунами.

slapin ★★★★★
()

Потому что конкретное решение задачи и поддерживаемый программный продукт - две большие разницы.

aedeph_ ★★
()

А может ещё программисту сидеть прокликивать свою программу, а гейм-девелоперам сутками напролет играть в их игры?

peregrine ★★★★★
()
Ответ на: комментарий от Iron_Bug

Всё зависит от масштабов проекта. Если хелловорлды пишут на команду, то документация не нужна. Если пишут монстра, то либо делают документацию, либо потом дружно сосут бибу.

peregrine ★★★★★
()

Я не знаю, как с точки зрения опыта - я, как правило, работаю один. Но в целом, с т.з. здравого смысла, это нормально.

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

В случае TDD я бы вообще сделал так, что тесты пишут аналитики (если, конечно, возможны аналитики с умением программировать хотя бы на таком уровне). Это типа такая работающая спецификация.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

В случае TDD я бы вообще сделал так, что тесты пишут аналитики (если, конечно, возможны аналитики с умением программировать хотя бы на таком уровне). Это типа такая работающая спецификация.

поздравляю, ты изобрел BDD

anonymous
()

Нормальный подход. Может быть как более, так и менее эффективным в зависимости от ситуации. Из плюсов - не отвлекать основного разработчика, проще вводить в проект джуниоров, более качественные тесты из-за незамыленного взгляда. А найденный баг писатель тестов обычно вполне может сам пофиксить.

ибо именно он лучше всех знает то что должно приходить на вход и выходить на выходе как правильный результат. Именно он знает что есть ошибка а что нет.

В вашем рассуждении тут основная ошибка. В нормальной разработке конечно же такой дикости нет чтобы разработчик единолично, да ещё и налету решал как должно работать API.

slovazap ★★★★★
()
Ответ на: комментарий от peregrine

ну, это теория. на практике я видела абсолютно монстрозные проекты, у которых вообще не было никакой внутренней девелоперской документации. документация была только юзерская. и приходилось разгребать тысячи файлов чужого кода и по нему разбираться, как всё устроено.

Iron_Bug ★★★★★
()
Ответ на: комментарий от rupert

А если реализация уже написана, и кто-то другой должен писать юнит тесты, не имея возможности изменить эту реализацию, то в этом нет большого толка, потому что нет того подспорья в разработке, которую дают юнит тесты.

Юнит-тесты позволяют фиксировать состояние реализации. Делаешь пуш в гит, а там автоматом сборка->запуск тестов, если что-то сломалось, то сразу видно. Может быть конечно и тест бажный, а не код, но это однозначно даст сигнал, что надо заняться изучением.

В этом и смысл.

Dudraug ★★★★★
()
Ответ на: комментарий от monk

Нет. Вот, например, есть задача «написать функцию, проверяющую, является ли треугольник равнобедренным». Если юнит-тесты пишет сам программист, то вполне может считать успешным код:

Это два подхода к тестированию «белого» и «черного» ящиков. Оба имеют права на жизнь и у обоих-двух есть свои плюсы/минусы.

Dudraug ★★★★★
()
Ответ на: комментарий от anonymous

спешите видеть, макака не видит дальше TDD, но имеет свое мнение

+1. юнит-тесты - это в первую очередь CI. На самом деле СI можно сделать так же и через ручное/полуавтоматическое/автоматическое(но не unit-тестирование). Но юнит-тесты один из основных инструментов для CI.

Dudraug ★★★★★
()
Ответ на: комментарий от Iron_Bug

самое ценное средство - это юнит-тесты.

Самое ценное - это не юнит-тесты, а CI. Юнит-тесты просто самое популярное, простое и удобное средство сделать CI.

Dudraug ★★★★★
()
Ответ на: комментарий от Miguel

Я выше уже все пояснил. Основная суть юнит-тестов - это CI. То что тест сломался, значит, что или ошибка в коде, или ошибка в тесте. В результате ты или фиксишь багу в коде(профит!!!), или багу в тесте. Фикс теста полезен тем, что тест улучшается и в будущем позволить продетектить косвенные и прямые проблемы в этом коде, или заставить тебя улучшить тест.

Если тесты постоянно улучшаются, то и кач-во тестирвания тоже. Ну и за счет «плохого» юнит теста ты делаешь дабл-чекинг своего кода, даже если он верный, а тест плохой. А дабл-чеккинг всегда хорошо.

Я объясняю очевидные вещи...

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

Основная суть юнит-тестов - это CI.

По-моему, ты говоришь примерно то же самое, что сказал я в своём первом комменте.

Miguel ★★★★★
()
Ответ на: комментарий от peregrine

Дык они ж этим все равно занимаются, разве нет?

Не вскую программу можно «прокликать». Тестирование штука сложная и разнообразная. И Unit-test'ы бывают разные. Есть тесты на соответствие API спецификации этого самого API. А есть тесты, которые при рефакторинге скажут, сломал ты всё или таки не всё. Бывают тесты, которые сам автор кода должен писать, а бывают те, которые он писать не должен, так как напишет плохо наверняка. Поэтому тут скорее все зависит от конкретного кода, который пишут и требований к нему.

slapin ★★★★★
()
Ответ на: комментарий от Miguel

По-моему, ты говоришь примерно то же самое, что сказал я в своём первом комменте.

Ты сказал, что они не нужны. Но это не так.

Dudraug ★★★★★
()
Ответ на: комментарий от Miguel

По-моему, юнит-тесты в обычном понимании — штука вообще почти бессмысленная.

Твоя цитата. Ты там конечно писал еще и про рефакторинг. Но CI нужен не только для рефакторинга, а так же и случае добавления новых фич, расширения API.

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

Твоя цитата.

Именно. Ключевые слова «в обычном понимании», т.е., как тесты.

добавления новых фич, расширения API

Юнит-тесты тут не помогут.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Юнит-тесты тут не помогут.

Помогут. Не панацея - да. Но помогут и будут полезны. И как я сказал выше, что если ты считаешь иначе, то ты не прав.

Dudraug ★★★★★
()
Ответ на: комментарий от slapin

Дык они ж этим все равно занимаются, разве нет?

Нет, этим занимаются тестировщики.

peregrine ★★★★★
()
Ответ на: комментарий от Iron_Bug

А компаниям не холодно и не жарко от того что отдел сосёт бибу. Это проблема сотрудников отдела.

peregrine ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.