LINUX.ORG.RU

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

 , ,


1

1

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

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

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

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

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

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

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

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

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

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

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

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

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

Объясните.



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

Ответ на: комментарий от foror

Паблик апи помимо тестируемости должно так же обладать определенным уровнем юзабилити. Ну если конечно есть конкуренты.

pon4ik ★★★★★
()

Можно понимать, как написать код поставленной задачи.
Можно понимать, как он должен быть написан.
Второе от первого отличается более детальным пониманием ТЗ, что позволяет написать (более) корректные тесты, особенно свежим взглядом. Да и «фактор автобуса» никто не отменял.
А привлечение к работе над проектом разных людей заставляет вести документацию, которую ни один разработчик сам для себя вести не будет.

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

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

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

Бесполезное занятие. Если подумать, зачем, вообще, существуют юнит тесты? Они помогают в разработке кода

Они компенсируют проверку на самые тупые ошибки или опечатки, которые обычно делает компилятор. Поэтому юнитами чаще кроют в интерпретируемых языках, это простой костыль, не более.

Попробовал представить как сеньор написал таск джуну скомпилировать его код ˆ_ˆ

Lordwind ★★★★★
()

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

anonymous
()

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

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

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

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

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

foror ★★★★★
()

Разве это нормально?

Если автор недостаточно компетентен, чтобы делать это самостоятельно, то пусть хоть кто-то это делает

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

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

По-моему, это аргумент скорее в мою пользу.

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

Так в идеальном мире за это денег должны больше, чем разрабам давать.

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

Deleted
()
  1. Дока должна быть, она важнее тестов.
  2. Сценарии развёртки тоже должны быть.

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

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

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

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

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

Внимание вопрос: к какому виду тестирования относится написание юнит-тестов? Не особо важно, в реальности или в идеале

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

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

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

В чьей теории? Лично я под функциональным подразумевал интеграционное, ручное протыкивание и проверку безопасности. Договаривай, в чём я по-твоему не прав? Желательно со сслыками на авторитетные источники.

WitcherGeralt ★★
()

Все сильно зависит от процессов в компании/команде.

Плюс тут в том, что автор кода уже предусмотрел все кейсы, о которых подумал и тесты он напишет в соответствии с ними. Другой человек обдумает задачу своим мозгом, посмотрит на нее иначе и, скорее всего, придумает такие кейсы, о которых автор кода не подумал.

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

Для команд, в которых есть автотестеры и работа над задачей ведется параллельно несколькими спецами, я бы взял вариант юнит-тестов от автора.

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

anonymous
()

Прочёл комменты.

Пожалуй, рискну высказать свою точку зрения.

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

2 Тесты так же полезны в случае, если проект долгий и все уже благополучно забыли про то, что там когда-то было. Т.е., чтобы ни чего не поломать ненароком в последствии.

3 Существующие методики как правило, либо не работают, либо работают хреново. Именно из-за того, что не автор кода пишет к нему тесты а какой-то маловразумительный олень. Олень не понимает как этот код работает, так что что он там собрался тестировать, одному Богу известно.

Я, на практике, придерживаюсь подхода, известного как test-driven development, который пришёл к нам из emdedded programming. Т.е., в данном случае программист не заканчивает тестами, он с них начинает и, в дальнейшем, на любом шаге проекта у него есть и граничные условия, которым надо удовлетворять и проверки на соответствие его кода этим самым граничным условиям. Ничего не нужно ни придумывать, ни извращаться как-то по-особому. Т.к. при таком подходе тесты являются неотъемлемой частью проекта, то в любой момент времени можно прогнать их и посмотреть что и где пошло не так в какой момент времени. Собственно, на их основе код и пишется. Это если объяснять просто и «на пальцах».

Рекомендуемая к прочтению книга (PDF!) Test-Driven Development for Embedded C by James W. Grenning. Да, это для С и для embedded, где в коде срать крайне не рекомендуется ибо чревато и не всегда есть возможность исправить положение во время исполнения кода. Но подход в принципе крайне трезвый на мой взгляд и здорово повышает продуктивность.

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

под функциональным подразумевал интеграционное, ручное протыкивание и проверку безопасности

прелесть какая. с умным видом хоть писал?

anonymous
()
Ответ на: Прочёл комменты. от Moisha_Liberman

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

ты описал не TDD, а test first. этого в принципе достаточно чтобы понять ценность твоей писанины

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

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

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

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

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

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

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

Разве что только в теории.

Ему, чтобы вкурить что же именно (про «как именно» и не говорим) надо тестировать, каковы кейсы применения кода, каковы граничные значения, для начала диздоки бы вкурить. А если их... нет? Или там уже всё сто раз поменялось, а программист, ныне уволенный за хроническое раздолбайство, не удосуживался вносить коррективы в сопроводиловку что, собственно и послужило причиной увольнения? И всё это было не вчера, а с годик назад и уже даже «старики не помнят».

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

Это так кажется, что пошёл, распинал джуна, поставил ему задачу и он все тесты нарисует. Может оказаться что работа сделана так, что лучше бы и не делалась. Т.е., тесты вроде как и есть, но по факту их и нет. Джуна тут винить не приходится, это не его вина. Требовать от джуна работу за сеньора это как-то неправильно по-моему.

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

Батенька...

Я бы с Вами согласился, если бы не дал ссылку на книгу. Test first это более общий случай test-driven. Это всё, что нужно знать о «ценности» Вашего мнения.

Очень жаль что Вы решили пукнуть в лужу из под анонима. Я бы сразу внёс Ваш ник в игнор. Надеюсь, в дальнейшем Вы предоставите мне возможность исправить эту досадную мелочь.

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

Сам же докопался, а сам же ноет, что зря тратит время, ну клоун же.

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

Я вынес за юнит тесты за скобки, ты к этому придрался, вот и всё. А время ты тратишь потому, что тебе заняться больше нечем, лишь бы докопаться на ровном месте.

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

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

pon4ik ★★★★★
()
Ответ на: Батенька... от Moisha_Liberman

TDD и test first вещи абсолютно ортогональные, а книг с TDD в названии всякими клоунами написано столько, что подтвердить ими можно любой бред. впрочем, к /0 это отношения не имеет, а лечить клоунов вроде вас я не нанимался

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

Милейший...

Стесняюсь спросить... Вы секс любите? О конечной точке своего назначения догадываетесь?

Ну так мне остаётся только пожелать Вам счастливого пути. Удачно добраться.

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

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

anonymous
()
Ответ на: Разве что только в теории. от Moisha_Liberman

А если их… нет?

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

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

Так если бы тесты изначально писал не он, это обнаружили бы раньше.

Может оказаться что работа сделана так, что лучше бы и не делалась

Джун не обязательно тупой, он просто не опытный. Умный джун по докам хорошие тесты напишет, а тупой это вообще отдельная проблема.

Нет, я не призываю так делать, но думаю, что подход имеет право на жизнь. Выше приводили плюсы.

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

Две балаболки этому царю!

У того, кто пишет тесты, мозги должны работать не так, как у того, кто писал код. Тогда можно будет выловить «логические» ошибки, но это не точно.

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

Да приложи уже что-нибудь. Все, неси спокойно свой бред в массы, в теме сказано достаточно чтобы грамотный человек мог сделать выводы

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

Да ктож спорит-то!

Надо написать.

Надо! Но сначала надо отодрать настоящим хреном тех, из-за чьего недосмотра их нет. И заставить исправить свою недоработку. Это на мой взгляд. Так будет, пожалуй, справедливо.

Но вот чтобы так не получалось, лучше использовать чужой опыт (ссылку дал) и не допускать ситуаций «а мы тут забыли». Просто потому, что «потом» это дороже. Всегда. Дешевле сразу и хорошо.

Про наличие ТЗ (пусть даже внутреннего, без передачи и согласования с Заказчиком) и не говорим. Это в обязательном порядке.

Так если бы тесты изначально писал не он, это обнаружили бы раньше.

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

Джун не обязательно тупой, он просто не опытный.

Да. Вообще-то, я не о тупости, а о неопытности. Но тогда это уже не джун, если он «джун с опытом». Тогда это уже миддл.

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

Почему бы не быть таким же «ломателям»-специалистам для функций?

Ты сам готов таким заниматься?

anonymous
()
Ответ на: Да ктож спорит-то! от Moisha_Liberman

И исходить из того, что они сами себе не враги

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

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

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

Ну, вот столкнется с этой функцией задрот-тестировщик, работающий в такой команде зазвездившихся кей девов и чё? У него есть только код - ни документации, ни тестов, т.е. ВСЯ информация доступна только из кода. Тут то ли ты нашел ошибку, то ли не понял, как использовать эту функцию. И че ему делать?

IMHO, такое положение вещей означает, что в команде бардак. Разрабы тупо пилят код и ни за что не отвечают. В таком случае это просто зазвездившиеся велосипедисты. Также, возможно, их на это сподвигли манагеры, например, по причине, что нужно быстрее-быстрее. Тогда все совсем плохо, потому что разрабы завалены задачами и, даже если захотят, все равно в этом бардаке ничего сделать не смогут. В результате у разрабов стресс, они пилят код, который сами не захотят поддерживать. У неудачников, которые разгребают рутину, сваленную на них, тоже стресс и они мечтают от этого побыстрее избавиться. Код превращается в хлам (технический долг растет), народ разбегается. Перспектив никаких.

anonymous
()

Если кей деву настолько насрать на свой код, что вломы написать тест, то почему кто-то другой за него это сделает хорошо, а не «на отвяжись»?

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

Понятно, терминологию путаем, какие-то нелепые отмазы включаем. Мне так показалось, что ты спрыгнул с юнит(как модульные) тестов, хотя ТС вещал конкретно про них, на то, что называется интеграционными функциональными тестами.

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

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

бля, вы затрахали уже, хоть один откройте ISO или ISTQB глоссарий, откройте того же Бека и уясните наконец, где виды, где уровни, где место юнит-тестов в тестировании, где место тестов в TDD, епт, это не бином Ньютона. 100500й раз одно и то же, 100500й раз нужно разжевывать как дошкольникам, надоело

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

Вот это уже ближе к теме, ругнись подробнее, что за Бек.

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

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

что такое должна производить компания, чтобы получить такое в отделе разработки? кучу математики и супер сложного анализа данных? ну так, один фиг этот математик и будет «незаменим», их на дороге не валяется.

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

system-root ★★★★★
()
Ответ на: комментарий от WitcherGeralt

Ну, тут уже...

Как говорится, вольному воля, спасённому Рай. Я тут ни чего не скажу.

Moisha_Liberman ★★
()
Ответ на: комментарий от system-root

кучу математики и супер сложного анализа данных?

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

WitcherGeralt ★★
()
Ответ на: комментарий от system-root

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

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