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

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

Да

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

Нет

прежде чем переключить свой контекст своего мозга на дельнейшие задачи

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

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

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

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

Объясните

Это ты от них требуй объяснений.

Это ты от них требуй объяснений.

Для этого ему придется сначала «объяснить» неправомерный доступ к информации...

Бесполезное занятие. Если подумать, зачем, вообще, существуют юнит тесты? Они помогают в разработке кода. Классический TDD: захотел ты сделать какой-то интерфейс у своего класса. Как узнать, хороший это интерфейс или плохой? Легко ли его использовать? Напиши к нему юнит тест. Если юнит тест получился корявый, или вообще никак не выходит, значит херовый интерфейс у тебя. А если реализация уже написана, и кто-то другой должен писать юнит тесты, не имея возможности изменить эту реализацию, то в этом нет большого толка, потому что нет того подспорья в разработке, которую дают юнит тесты.

ССЗБ

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

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

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

bool isIsosceles(double a, double b, double c)
{
    if (a == b) {
        return true;
    } else {
        return false;
    }
}

test(isIsosceles(1, 1, 2), true);
test(isIsosceles(1, 2, 3), false);

Все ветки кода протестированы, все тесты проходят.

А другой человек вполне может сформировать тест isIsosceles(1, 2, 2), так как он видит описание задачи, а не ветки кода.

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

Очевидно же что именно автор кода может (и должен) подробно проверить свой собственный метод, класс, модуль

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

проблема в том, что нубу дольше объяснять, что и как надо тестировать, чем написать самому. тем не менее, общие тесты, которыми занимаются QA, нужны.

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

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

Как узнать, хороший это интерфейс или плохой?

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

Если первое, то сам потом и протестируешь насколько он удобен расширяя код, используя ранее написанные интерфейсы. Если паблик АПИ, то тут тесты не помогут, тут обязательно нужен взгляд со стороны. Разраб понимающий внутренние кишки может просто не понимать, что его паблик АПИ полное УГ для сторонних разрабов.

не имея возможности изменить эту реализацию

С какого? Это же не стороннее ПО, все разрабы рядом сидят, если тот, кого на тесты бросили, видит хреновое АПИ, то он сообщает об этом изначальному разрабу. И тот исправляет.

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

вот это точно ненормально.

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

подробнейшим образом проверить

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

Вы, конечно же, абсолютно правы. И вы молодец, что задались этим вопросом.
Хороший разработчик тем и отличается от плохого, что решает _бизнес задачу_, тогда как плохой программист программирует потому что, видите ли, ему нравится программировать. А писать юнит тесты — слишком скучно.
Хороший разработчик пишет и тесты и документацию, и сценарии развертывания и много чего еще. И самое главное — он несет полную ответственность за то, что он сделал (решил бизнес задачу с _помощью_ написания кода и сопутствующих вещей). Можно ли быть уверенным в работе функционала без тестов? Нет, нельзя.
Не даром говорят, что понимание бизнеса — это самое главное. В общем, для понимания всего этого надо прочитать много книг. Советую начать с основ капитализма, принципов работы коммерческой организации, бизнес-процессов и прочих, относящихся к этой теме, вещей.
Вот вы можете представить себе разработчика, который пишет код для прошивки какого-нибудь лунохода или космического зонда и который не написал к этому тестов? Я — нет.
А так вообще забейте на это — хуже только для компании: с учетом, что она ведет неверный процесс разработки ПО велика вероятность, что она разориться и освободит дорогу другим компаниям, где это понимают.

проблема в том, что нубу дольше объяснять, что и как надо тестировать

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

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

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

Объясните

Идиоты, сэр. Правильно, это когда они отправляют делать тесты под аудиозапись того круто чувака. Это деловые отношения вида, например, врача и медицинской сестры в США. То есть эти, откровенно говоря, дураки, слышали звон, да не знают где он. Почти все хитровыепанные схемы, которые вызывают вопросы, это лень приправленая глупостью.

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

может ли разработанной библиотекой пользоваться кто-то кроме самого разработчика.

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

Заказчика - нет. А руководителя группы программистов - да. Если человеку поручили, например, написать библиотеку для работы с JSON (чтобы можно было делать экспорт и импорт данных во внешние системы), но он написал её так, что использовать (а тем более модифицировать) может только он сам, то лучше заставить его переписать по-человечески.

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

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

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

Ну и вот.

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

а он даже и не знает что как работает там.

в этом и есть бессмысленность подобной активности.

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

Это слишком простой случай.

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

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

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

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

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

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

А вот в плане облегчения рефакторинга — да, нужная весч. Проверить, что от рефакторинга ничего не сломалось, и новый вывод совпадает со старым — бесценно.

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

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

но и статическими и динамическими аналазиторами, не полениться позапускать генерацию покрытия кода типа gcov/lcov - для всего кода в области своей отвественности

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

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

тут согласен

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

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

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

Прямо по классике: «Печатаю быстро, но такая фигня получается»

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

Юнит тесты - это вообще по определению тесты написанные и выполняемые в том же контексте.

Юнит тесты - это вообще по определению тесты написанные и выполняемые в том же контексте.

именно.

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

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

Это другой тип тестирования, у него другие задачи.

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

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

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

Контекст, это та логика, которую ты держишь в голове когда пишешь кусок кода. И ровно та же, которая нужна для его unit-тестирования.

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

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

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

Для сложных ситуаций контекст меняется с кода на входные данные.

А код ты типа пишешь не задумываясь о входных данных? Просто так? Как ты вообще определяешь что пишешь нужную функцию? Что дописал её до конца и можно переходить к следующей? Что выполнил поставленную задачу?

Ты не можешь не думать об этом в процессе «кодирования», это обязательная часть контекста. И собственно вот за этим и нужны юнит тесты, чтобы пока ты копался в одной конкретной ветке одной петли цикла, не забыл вообще зачем ты здесь.

И не тестировщик спустя неделю должен тебе об этом напоминать.

А код ты типа пишешь не задумываясь о входных данных?

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

Как ты вообще определяешь что пишешь нужную функцию?

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

пока ты копался в одной конкретной ветке одной петли цикла, не забыл вообще зачем ты здесь

Если речь о фиксинге багов, то можно и комментарий даже не оставлять, нужный человек, все данные для написания теста получит из issue tracker.

Всё гораздо хуже https://medium.com/pacroy/why-most-unit-testing-is-waste-tests-dont-improve-q...

Извращения от обнаглевших и зазвездившихся кей девов.

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

Их и опиши в документации к коду с примерами для тех

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

Я говорил о тестировании подсистемы из множества функций.

Внезапно это тред про юнит-тесты. Тестирование подсистемы это другой тип. Тестов вообще бывает много и разных.

А куда смотреть дальше tdd, поведай о мудрейший?

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

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

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

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

Внезапно это тред про юнит-тесты. Тестирование подсистемы это другой тип. Тестов вообще бывает много и разных.

Внезапно, но в ООП нет понятия функций и обычно тестируются классы, а это уже подсистема, если что.

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

Как тебе самому не дали просраться с такими глубокими познаниями - загадка. Может гасились прост и считали тебя биофаззером?

Публичное api в приличных местах проектируют.

Ахаха, так это значит андроидное, уродливое АПИ, за которое теперь даже стыдно изначальному автору, проектировалось в приличном месте? )

А юнит тесты это инструмент разработки тонкостей реализации.

А паблик АПИ это не тонкости реализации? Это просто так, да?

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