Почему тесты не пишут вместе с кодом?

Особенно круто выглядело б жс-библиотеках, где сам код минифицируется, ну куда там тесты? Последние иногда весят крайне много.

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

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

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

Тесты же будут обработаны машиной.

Э??? Тесты только я читаю, чтобы понять какие случаи предусматривает функция?

Если этого нет в комментариях (код, внезапно, надо комментировать, и это один из моментов, который должен быть в комментариях), то беда в том, кто писал.

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

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

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

да я вон приводил пример с автодоком … и просто так их из кода не вынести

Опять же, пример Racket. Там аналог автодока (scribble/manual) именно в отдельном файле. Обоснование то же самое, что в этой теме для тестов (документация не должна мешать в файле с кодом).

Я всё-таки про юнит-тесты. И про ситуацию, когда один и тот же код в двух-трёх местах (в виде теста, в виде комментария перед функцией, в виде документации). И когда при изменении поведения функции приходится все эти три места синхронизировать.

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

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

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

Вот именно, круто при разработке, ненужно в проде.

без ущерба для производительности сборки

Ну да, если это будет в какой-то директиве препроцессора, мол, это удалить, то норм.

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

ППКС, увы.

сообщения не может, может темы

Да.

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

Никак. Код должен быть самодокументируемым именами функций и переменных. Алгоритмы, описание API для пользователя библиотеки и вся математика должна быть в отдельном файле с поддержкой разделов, ссылок и оформления. Так принято.

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

Добавить код и не добавить тест очень легко. Особенно когда добавляются флаги-режимы.

ага, я уже обнаружил это The scribble/srcdoc and scribble/extract libraries support writing documentation within the documented code along with an export contract, similar to using JavaDoc. With this approach, a single contract specification is used both for the run-time contract and the documentation of an exported binding.

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

Когда они разрастаются до размеров документации, то безусловно. Вон man-ы никто в здравом уме вместе с кодом не держит.

Не писать простыни из комментариев больше, чем это необходимо - не вариант?

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

Если этого нет в комментариях (код, внезапно, надо комментировать, и это один из моментов, который должен быть в комментариях), то беда в том, кто писал.

В смысле? Все случаи, проверенные в тестах, продублировать в комментарии? Нигде такого не видел.

О чём и речь. Если модуль объёмный и кода много, то пришла пора его резать, даже по простым соображениям - невозможно адекватно удерживать в голове 100500 низкоуровневых абстракций распухшего модуля и пора переходить к более высокоуровневым абстракциям. Другое дело, что обычно нет времени на то чтобы резать и писать нормально, потому на выходе имеем монстров вроде Oracle Database где исправление одной маленькой ошибки занимает по несколько дней. Зато её сразу наговнокодили, без всякого там проектирования и подумать, что позволило в своё время занять ей вершину рынка, правда рано или поздно postgresql смешает её с какашками и вот уже его с этой вершины будет сдвинуть нереально, что мы и наблюдаем - Oracle Database жива только за счёт легаси и ряда заказчиков которые к ней очень привыкли.

Oracle Database жива только за счёт легаси и ряда заказчиков которые к ней очень привыкли.

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

И эта стратегия до сих пор отлично работает, и будет работать: в 2021 году Oracle показала вроде хорошую прибыль.

Нет, все случаи, для которых работает функция нужные, чтобы человек её понял. Или вам по приколу надо больше однотипных случаев?

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

Микросервисы в Java не так просто протащить пытаются, а как раз чтобы пухлые программы не появлялись (а это основная проблема Java). Просто сама Java как язык этому очень сопротивляется, там одни названия методов способствуют опуханию кода.

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

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

Нет, все случаи, для которых работает функция нужные, чтобы человек её понял. Или вам по приколу надо больше однотипных случаев?

Так в тестах ведь случаи не однотипные, а как раз краевые. Вот, кстати, хороший пример: https://docs.rs/bitflags/latest/bitflags/

Тесты один раз в документации: https://github.com/bitflags/bitflags/blob/main/src/lib.rs#L35 (дважды: https://github.com/bitflags/bitflags/blob/main/src/lib.rs#L315), а второй раз как тесты: https://github.com/bitflags/bitflags/blob/main/src/lib.rs#L1227

Причём, примеры в тестах полнее: есть оператор ^, который в документации вообще не упомянут. То есть здесь проще прочитать тесты в конце файла, чем (неполную) документацию.

Тесты не заменяют комментарии, у них даже цели такой нет. На тест можно ссылаться из комментария, но комментарии всё равно должны быть и должны объяснять код.

JB - вендорлок, а вендорлок - зло.

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

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

ЗЫ

Завтра чебурнет наступит и vscode прекратит работу.

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

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

Они являются примерами для комментариев. В Haskell.

У остальных так не принято.

Почему тесты не пишут вместе с кодом?

Мне так вообще не понятно как работают тестировщики.
Ведь для разработки теста нужно досконально понимать как работает алгоритм.
Да и всегда ли нужна разработка тестов?

Не пишу тестовый код. API предназначен для получения чегой-то там и это чегой-то там обычно какая то решаемая задача.
Вот ее то и ОТЛАЖИВАЮ /конечно и разрабатываемый API также отлаживается/.

Не утверждаю, что тесты не нужно разрабатывать.
Здесь все зависит от

СИТУАЦИИ ...

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

Не утверждаю, что тесты не нужно разрабатывать.

Есть задачи в которых тесты нужны и их должны быть ВАГОНЫ.
Например, компиляторов …

Модуль для удобства организации. Можешь его затереть и рядом с каждой функцией писать #[cfg(test)]. Или чего ты вообще хочешь?

Это не зависит от расположения тестов и решается покрытием.

Или чего ты вообще хочешь?

Я уже приводил идеальный вариант: https://hackage.haskell.org/package/vector-0.12.3.1/docs/src/Data.Vector.html#iterateN

Тесты непосредственно перед кодом. Комментируют и иллюстрируют его.

У меня так

// ----------------
// --- Если производится binding числового параметра
//
 if ( ValueParam.vt == VT_R8 ) {

  iRetCode = ::sqlite3_bind_int(                           // Evaluate the statement
   (sqlite3_stmt *) pStmt,                                 // Результат prepared SQL строки
   (INT)            IndexParam.dblVal,                     // Index параметра в наборе параметров /параметров может быть несколько/
   (INT)            ValueParam.dblVal                      // Значение параметра
  );

// --- Произошла ошибка при выполнении функции sqlite3_bind_int()
//
  if  ( iRetCode != SQLITE_OK ) {

   pErrorMessage = ::sqlite3_errmsg(                       // Получаем текст сообщения об ошибке
    m_hSQLiteDatabase
   );

   vpResult.dblVal = iRetCode;
   *bResult        = vpResult;                             // 

   return  hr;

  }                                                        // if  ( iRetCode != SQLITE_OK ) {

 }                                                         // if ( ValueParam.vt == VT_R8 ) {

Владимир

А. Ты хочешь тесты В комментариях; то, что называют doctests. Такое тоже есть https://doc.rust-lang.org/src/std/fs.rs.html#2143-2145

Почему так не делают все - для меня загадка.

Бюрократия с тестами нужна только если контора достаточно крупная

Что считать крупной конторой? Конкретно у нас по «последним сводкам с фронта» что я видел - порядка 2k сотрудников. Это много или мало?

чтобы любой факап выливался в миллиарды нефти.

Прямые финансовые потери от нашего последнего серьезного fsckup’а превысили сотню лямов убитых енотов. Слава богу - больно, но не смертельно. Я опять же не знаю - по Вашей шкале это много или мало.

Мелкой конторе эффективнее выкатить сырой продукт и порешать проблемы напрямую с клиентами.

Как будем оценивать репутационные потери?

Ты хочешь тесты В комментариях;

Не обязательно В комментариях.

Можно так: https://github.com/CameronBoudreau/programming-language-classifier/blob/master/data/scheme/common.rkt

;; -----------------------------------------------------------------------------
;; (=α e_1 e_2) determines whether e_1 and e_2 are α equivalent

(module+ test
  (test-equal (term (=α (lambda (x) x) (lambda (y) y))) #true)
  (test-equal (term (=α (lambda (x) (x 1)) (lambda (y) (y 1)))) #true)
  (test-equal (term (=α (lambda (x) x) (lambda (y) z))) #false))

(define-metafunction Lambda
  =α : any any -> boolean
  [(=α any_1 any_2) ,(equal? (term (sd any_1)) (term (sd any_2)))])

Всё наглядно и тесты проходят синтаксическую проверку (в отличие от тестов В комментариях).

репутационные потери

Для мелкой конторы «рога и копыта» их нет. Потому что нет репутации.

Прямые финансовые потери от нашего последнего серьезного fsckup’а превысили сотню лямов убитых енотов

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

порядка 2k сотрудников

Ни о чём не говорит вообще. Крупность определяется по клиентской базе.

репутационные потери

Для мелкой конторы «рога и копыта» их нет. Потому что нет репутации.

Репутационные потери? Да и пёс с ними, откроем новую контору, чистенькую с незапятнанной репутацией, наймем новых представительных лиц и пару старых (которые всей прошлой клиентской базе которая была у конторы скажут, что нашли новую, в которой все как в лучших домах ландона и вообще по красоте, надежная, не дорогая, 100500 успешных проектов и счастливых заказчиков), старый штат работяг, я уже и название придумал ТОО «Я сделяль», погнали.

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

Репутационные потери? Да и пёс с ними, откроем новую контору, чистенькую с незапятнанной репутацией

Я не думаю что с таким подходом «серьезные дядьки» захотят иметь с Вами дело. После «первого раза».

ну это же была ирония, скорее всего не захотят.

откроем новую контору

Ненужно. Если вас и так никто не знает, зачем менять одно ноунейм на другое? Достаточно ребрендить продукт и вуаля. Это если все полимеры уже просрали. А так, я уже говорил, проблемы можно решать непосредственно с потребителями. Крупная контора, это именно такая, что кастомеров слишком много и с каждым уже не порешать.

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

Речь про контору из реального сектора с ИТ отделом, а не про галеры. На галере выбора нет, там заказчик решает. Но заказчик при этом руководствуется теми же принципами. Люди которые навеливают всестороннее тестирование поступают навроде птички из мультика «лучше день потерять, потом за час долететь». Бизнес, особенно мелкий не может позволить медлить: кто первый встал того и тапки. Задачи ИТ отдела заключается в том чтобы способствовать зарабатыванию денег, а не вылизывать код до блеска. Это обычно могут себе позволить господа из опенсорса, т.к. они «продают» именно идеальный код, а времени у них вагон.

Речь про контору из реального сектора с ИТ отделом, а не про галеры. На галере выбора нет, там заказчик решает. Но заказчик при этом руководствуется теми же принципами. Люди которые навеливают всестороннее тестирование поступают навроде птички из мультика «лучше день потерять, потом за час долететь». Бизнес, особенно мелкий не может позволить медлить: кто первый встал того и тапки. Задачи ИТ отдела заключается в том чтобы способствовать зарабатыванию денег, а не вылизывать код до блеска. Это обычно могут себе позволить господа из опенсорса, т.к. они «продают» именно идеальный код, а времени у них вагон.

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

Ненужно. Если вас и так никто не знает, зачем менять одно ноунейм на другое? Достаточно ребрендить продукт и вуаля. Это если все полимеры уже просрали. А так, я уже говорил, проблемы можно решать непосредственно с потребителями.

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

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

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

может быть и прокатит

Не может быть, а так это и работает.

если вы продаете услуги по изготовлению продуктов

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

получается что это не крупная контора, кастомеров то всего два, и не важно что это гипотетический IBM и Intel например

Да это не важно. Важно что все детали и все последствия можно решать с конкретными лицами.

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

Сложный это вопрос.
Мне вот не понятно как можно покрыть тестами даже отдельный алгоритм.
К примеру алгоритм использует много if, … и как можно в тестах учесть все логические цепочки?
Написать новый код, который будет логически как-то там анализировать логику алгоритма?
Хотя конечно какую-то основную часть логики можно покрыть какими-то наборами исходных данных.

Кто из форумчан имеет опыт разработки тестов?
Поделитесь инфой насколько они полезны и когда …

А мы ЛОХ-и послушаем и поучимся ... 

Если ТУПИТЬ будете

ОТРУГАЕМ! ...

Не может быть, а так это и работает.

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

Да это не важно. Важно что все детали и все последствия можно решать с конкретными лицами.

то есть вы хотите сказать что если заказчиков больше какого-то количества, то вы перестаете иметь выход на этих «конкретных лиц», звучит довольно странно эта взаимосвязь зависящая от количества заказчиков. Вы либо можете найти способ договориться либо не можете, и сколько у вас заказчиков не играет никакого значения. Тем более что есть все-равно предел тех, с кем вы можете себе позволить заключить договор, просто потому что у вас есть определенный штат и он физически не может разрабатывать больше продуктов чем его предел даже если будут кранчить 24 на 7. Это если смотреть на аутсорс и продажу услуг, если смотреть на продажу уже готового продукта копиями предела в принципе почти нет. Как видите разница все-таки есть в том, что именно вы продаете.

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

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