Коллеги, как вы решаете вопрос с тестированием своего кода? Вы уверены, что ваш код отрабатывает так как вы планировали?
Представим себе ситуацию, что вы дорабатываете, что то сложнее чем внешний отчет в erp.
Вот вы написали код и вроде бы все должно быть прекрасно. Что делать дальше? Надо бы запустить наш прекрасный код на выполнение.
Тут возникает примерно такой вот диалог
(в) На чем тестить?
(о) на данных))))
(в) На каких?
(о) давай возьмем у заказчика
(в) у нас 20 разработчиков, которые «пилят различный функционал» существующая база заказчика весит 500гб. Думаю все понимают что это не вариант…

Дальнейшее развитие выглядит примерно так: заполняем тестовую базу какими то далекими от реальности данными (очень часто разработчики не полностью владеют предметной областью) и как то тестим. При этом при каждой маленькой ошибочке, на действительно больших конфигурациях, ждем по 30 минут после каждого F7. И после всего этого после передачи заказчику оказывается что на их данных все отваливается и уже устойчивая мысль, что при каждом обновлении  конфигурации все ломается, крепчает у заказчиков еще больше.

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

тестировать хотя бы на данных сопоставимых размеров...

1. Код должен тестироваться на данных заказчика.
2. Заказчик должен обеспечить разработчика нужными данными.
3. У разработчика должна быть техническая возможность эти данные разместить у себя. Либо заказчик предоставляет ресурсы для тестирования.

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

Нужно различать тестирование алгоритмов и тестирование производительности

(0) [ Вы уверены, что ваш код отрабатывает так как вы планировали] да
[заполняем тестовую базу какими то далекими от реальности данными] тестируем на копии продуктива по согласованному сквозному контрольному примеру с параллельным выполнением на эталонной копии, всякое расхождение документируем и изъясняем

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

(0) Гы, как по этой жизни можно быть в чем-то уверенным? Я не уверен в том что доживу до вечера - может инсульт, может машина собьет. Вероятность такого события не велика, но она есть. А вы про какой-то код :))

(0) "устойчивая мысль, что при каждом обновлении  конфигурации все ломается, крепчает у заказчиков еще больше."
Такая СеЛяВа. И это нужно донести до заказчика. Или заказчик должен оплатить качественное тестирование. А это ~ 70% от общей стоимости. И тогда тестируйте по полной.

(2) +100500

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

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

(8) кто не содержит собственную армию - тот содержит чужую (с)

(3) Я бы не стал. А потом встанет вопрос: а кто будет тестировать программу для тестирования?

Лучше уж пусть человек сядет и потычет.

(8) нужно регрисионные тесты просто делать,тогда ломаться будет на пару порядокв меньше

Вау, как быстро....
Давайте уточню, про производительность не шла речь, это отдельный вопрос, при котором на тестирование на "реальных данных" обязательное условие - ИМХО

(14) Тест - это просто тест. Любой. Хоть даже и регрессионный (правда я не понял к чему оно((( ). Оно от "поломок" не защитит. Тест поможет выявить логическую ошибку.
Но! Как сказал ТС - только на конкретном наборе тестовых данных. Отсутствие ошибок на одном наборе абсолютно не означает их отсутствие на другом наборе.
Вот ТС и пытается понять - какое количество наборов нужно для более менее достоверного тестирования. И кто эти наборы будет готовить.
Как то так.

база 500 гб - можно каждому разрабу позволить присовременых ценах на хдд.

(16) Именно, спасибо вам

(17) Это больше похоже на мечты, потому что таких проектов может быть больше одного

Что за тупой вопрос? Моделируется ситуация и тестируется. С вводом данных. По возможности применяю метод, принятый в ВВС США - модель должна быть такая, что проверяются все существующие ветки алгоритма.

(16) И еще дополнение как эти наборы будут создаваться, ввиду того что в платформе слой данных не отделен от слоя логики

(20) Вы часто это делаете?

(21)[ввиду того что в платформе слой данных не отделен от слоя логики]
очевидный бред

(19) Без копии реальной базы, пускай не с последними данными - никуда. Раз в неделю восстанавливать копию рабочей, накатывать на неё все наработки, на ней и тестировать. Если не каждому разрабу, то по копии на каждые 5 человек. Ненужные данные ради уменьшения объема можно и прямыми запросами удалить.

(23) Правда?? Я аргументирую, невозможно создать и записать объект предметной области в имитацию бд (речь про бд в памяти)

(24) Ну то есть в течении недели вы не совсем понимаете можете ли вы выпустить релиз сейчас или нет? Это не упрек, я правда пытаюсь понять как обстоят дела у "других"

(16) тестиирование не защищает на 100%, а уменьшает количество ошибок

(20) Это называется 100% покрытие кода тестами

80% кода будут работать если ты просто один раз взял, запустил и оно работает.

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

Тестирование вскрывает только очевидные косяки.

(27) бесспорно, но мне кажется мы все таки удаляемся от основного вопроса, он звучит так: "Как вы тестируете свой код"

А можно узнать, что это за контора, где есть 20 разработчиков, но нет возможности развернуть тестовую, пусть и 500гб базу заказчика? И зачем вы беретесь за такие проекты?

(26) А зачем обновляться чаще раза в неделю? Что за жареный петух вас клюет? Или "хренась-хренась и в продакшен"?
Имхо, если 20 человек пилят одну базу - частые обновления приведут к хаосу. Должно быть время на "вылизывание" релиза перед накатыванием в рабочую базу.

(30) лично я пишу тесты

(29) В моем понимании тестирование это набор "шишок" которые мы набили ранее и будем стараться не допускать в будущем, увы память (человечекая) для хранения всех этих "шишок" с моей точки зрения для этого не подходит

Например такие
https://github.com/a-sitnikov/erp2_xtests

Если ситуация сложная, то как тестировать надо думать заранее.
И почему это базу в 500 Гб дублировать для целей тестирования это не вариант?
У меня, например, есть такой вариант построения тестового контура.
Одна база является полной копией рабочей, каждую ночь копируется. Это для всяких экспериментов над продуктивом и реальными данными, для воспроизведения ошибок в продуктиве и все такое.
Вторая база также каждую ночь поднимается из рабочей, а утром в нее накатывают конфигурацию из хранилища разработки. Это получается база для тестирования алгоритмов разработки на актуальных данных.
В третью базу тоже ежедневно загружается конфигурация разработки, то актуальными данными она автоматически не обновляется, только по запросу. Это чтобы долговременные тестовые примеры не затирались.

И да, рабочая база у нас как раз 500гб. Но вот ее тестовые копии 100-150, потому как из них версии удаляем и саму базу сжимаем.
У каждого программиста база с данными и по запросу она актуализируется свежей копией.

(32) Этого жаренного петуха обычно называют критический релиз

Ну и вооще континуус интегрэйшн придумали уже давно

> Думаю все понимают что это не вариант…

почему не вариант ?

есть такая профессия: тестировщик

(40) у вас тестировщик тесты пишет или ручками прокликивает?

(35) А ты можешь видос записать и на ютуб выложить как ты это делаешь?

(34) Тестирование это хорошо, когда помещаешь релиз и вдруг оказывается, что форма заказа тупо не открывается - тупо две команды написали противоречащий код.
Правило Паретто, 20% усилий дают 80% результата. Тестирование вот и должно давать 80% результата за мелкие усилия. Простая обработка которая прогонит важные формы и объекты. Гнаться за 100%, называя это покрытием кода или ещё какой глупостью, имхо, не надо. Надо усилия в другом месте приложить - толку будет больше.

(25) [невозможно создать и записать объект предметной области в имитацию бд (речь про бд в памяти)]
начните с азов, отличия неймановской и принстонской архитектур

(0) выпускаем отраслевое решение для 50+ филиалов по России
Есть копии почти всех баз.
После разработки тестируется на нескольких самых больших базах. Раз в 3 месяца выпускается бета релиз, регионы уже сами тестируют, если хотят. После этого выпускается нормальный релиз.

(41) я не знаю ни одного тестировщика, пожтому не могу сказать как они работают

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

А кто-нибудь юзал 1С:Сценарное тестирование?

(42) я бы тоже посмотрел такое видео, т.к. хочется освоить автотесты, надоело руками тестировать.

(48) юзали, очень не удобно, не надёжные в плане выполнения, отваливаются по не понятным причинам, спасает перезапуск

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

(45) спасибо, ознакомился

Иногда настраиваю автоматическую миграцию данных из рабочей инфобазы (или ее копии) в ЦТБ (центральную тестовую базу)

Это закрывает вопрос об имении актуальных реальных данных у разработчиков

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

Даже 1с не позволяет себе на 100% тестировать свой продукт.

А так у 1с есть статья по этому поводу. Она рекомендует по мимо рабочего сервера (сервер заказчика с реальными данными) иметь еще 3 промежуточных сервера: сервер разработчика (с тестовыми данными), сервер тестирования (тестовые данные) и подготовительный сервер (с пользовательскими данными). Т.е. не нужно каждому разработчику давать реальную базу

Источник https://its.1c.ru/db/metod8dev#content:5905:hdoc

(51) Тестовые наборы можно готовить через xUnitFor1C
https://github.com/xDrivenDevelopment/xUnitFor1C/wiki/Тестирование-через-образец-исходных-данных
Пользуемся иногда. Вполне себе работающий механизм.
А против (43) еще помогает практика code review. Прямо сильно помогает.

(57) великое открытие на 30 году существования вендора
dev
uat
test

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

(58) только вот код ревью должен быть всегда, а не выборочно

(61) А кто его (по феншую) должен осуществлять? Напарник (параллельно к тебе в должности) или какой-нибудь вышестоящий гуру?

(62) тимлид

спасибо всем, я в принципе получил ответы на свои вопросы

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

(64) ТЗ естественно нет?

(66) больше чем тз, обследование и тех проект есть, но только это не решает вопрос удобства тестирования

(67) обследование и тех проект это больше чем ТЗ!? не смешите

(61) (62) (63)да, ревью должны быть постоянными. Очень помогает чек лист: проверяем форматирование, разыменования в запросах, осмысленность имён переменных и методов, возможность завершения циклов и и тд. Если есть разногласия по пунктам не из чеклиста, решаем по ситуации. Главное - даже не догма, а здравый смысл.
Тимлидов на весь код не хватает, простые вещи спокойно проверяют мидлы. Плюс появляются общие стандарты кода и общее владение кодом, копипасты меньше.
Минус - это небольшое удорожание разработки. Плюс - не так страшно на продакшн выкладывать, техподдержке легче, и продукт не так быстро становится горой костылей.
Одно только понимание, что твой код будут читать, заставляет писать по человечески. Особенно когда с этими читателями вместе обедать ходишь.

(69) через гит ревью делаете?

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

(70) когда как. Чаще всего все-таки через конфигуратор, там удобнее навигация по коду. Результаты фиксируем в рамках тикета на разработку в jira или gitlab.
В вебе гитлаба иногда смотрим blame, если надо быстро понять, кто это накодил. Гитовый клиент у нас sourcetree, там тоже мельком посматриваем, кто над чем работает в данный момент, какие новости в коде, где предстоит тяжёлый мерж и и.д.

(72) но ведь сравнение версий в конфигураторе - это потеря полчаса времени

(73) нам проще, пишем внешние обработки. Там порядка 100 000 строк кода и от 50 до 130 форм, но конфигуратор это пережевывает, понятно, быстрее, чем соседние релизы erp.
Зато с ветками удобно, и объединять интереснее.

(0) Тестовый набор данных подписывается у заказчика как часть ТЗ. Если на них работает - значит продукт написан качественно, подписывается акт, получаются деньги.

(37) Подождут.

(73) От объема изменений зависит. Бывает и 1-2 минуты.

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

(78) Ты недооцениваешь способности пользователей. Иногда они изобретают такие комбинации данных, которые тебе сроду в голову не придут. Так что все возможные варианты не предусмотришь. Поэтому пишутся тест-кейсы, в в которых предусмотрены определенные наборы данных и по этим кейсам  тестится разработанное ПО. Если в рамках кейса косяков нет, то считаем что ошибок нет. Но на самом деле ошибки все равно есть, просто они пока еще не проявились.
Бывает так, что ошибки проявляются только при каких-то определенных обстоятельствах. Например на разных компах,  на одном и том же наборе данных, на одном компе ошибка есть, а на другом нет. Недавно боролись с масштабированием УФ, на одном компе все масштабируется, а на другом нет. Оказалось, что на одном компе стояли не все обновления или как-то криво стояли. В общем сделали все одинаково, все заработало.

"все возможные варианты не предусмотришь" // Дарю: "иначе"

+(80) "Иначе ВызватьИсключение "Неождаемое поведение, ололо, разбирайся""

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

(82) с разными версиями пользователей особенно.