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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

продолжайте наблюдение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аргументируешь, клоун, или просто на хер пойдёшь?

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

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

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

что он там собрался тестировать

Интерфейсы, граничные значения, не?

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

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

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

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

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

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

Батенька...

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

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

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

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

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

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

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

Милейший...

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

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

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

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

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

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

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

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

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

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

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

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

Ну, то есть ты здесь только за тем, чтобы покукарекать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я не готов это обсуждать.

Если честно. Наверное, такой подход имеет право на существование, но я не уверен в этом.

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

Права не имеет, но существует. Это нужно учитывать.

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

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

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

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

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

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

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

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

словить там bus factor можно только в моём воображении усть-ужопинска

Например, если код написан в таком стиле: Как в си узнать домашнюю папку? (комментарий)