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

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

Это, как любят писать в англоязычных форумах, не делает нас счастливее.
Из всего выше сказанного вопрос: «как вы решаете эту проблему?»
1 dezss
 
14.06.18
10:50
тестировать хотя бы на данных сопоставимых размеров...
2 VladZ
 
14.06.18
10:50
1. Код должен тестироваться на данных заказчика.
2. Заказчик должен обеспечить разработчика нужными данными.
3. У разработчика должна быть техническая возможность эти данные разместить у себя. Либо заказчик предоставляет ресурсы для тестирования.
3 lodger
 
14.06.18
10:51
можно(или нужно?) тратить отдельное время на написание автотестов, которые имитируют деятельность пользователя, в том числе ввод данных.
4 Вафель
 
14.06.18
10:52
Нужно различать тестирование алгоритмов и тестирование производительности
5 shuhard
 
14.06.18
10:53
(0) [ Вы уверены, что ваш код отрабатывает так как вы планировали] да
[заполняем тестовую базу какими то далекими от реальности данными] тестируем на копии продуктива по согласованному сквозному контрольному примеру с параллельным выполнением на эталонной копии, всякое расхождение документируем и изъясняем
6 VS-1976
 
14.06.18
10:53
(0) 1-е правило чтобы упростить код и уменьшить стоимость поддержки, данные должны быть введены всегда в правильном формате.
2. Как и сказали выше данные должны быть. Часто для выявления нюансов не напишешь код, который будет адекватно отрабатывать при различных входящих данных
7 spectre1978
 
14.06.18
10:53
(0) Гы, как по этой жизни можно быть в чем-то уверенным? Я не уверен в том что доживу до вечера - может инсульт, может машина собьет. Вероятность такого события не велика, но она есть. А вы про какой-то код :))
8 Остап Сулейманович
 
14.06.18
10:53
(0) "устойчивая мысль, что при каждом обновлении  конфигурации все ломается, крепчает у заказчиков еще больше."
Такая СеЛяВа. И это нужно донести до заказчика. Или заказчик должен оплатить качественное тестирование. А это ~ 70% от общей стоимости. И тогда тестируйте по полной.
9 olegves
 
14.06.18
10:53
(2) +100500
10 shuhard
 
14.06.18
10:55
(0)[И после всего этого после передачи заказчику оказывается что на их данных все отваливается и уже устойчивая мысль, что при каждом обновлении  конфигурации все ломается, крепчает у заказчиков еще больше. ]
очередной ЦКП ждёт смена начальника отдела, это нормально
11 Вафель
 
14.06.18
10:55
Ну и вообще желательно писать код так чтобы можно было тестировать модульно, каждую функцию отдельно
12 olegves
 
14.06.18
10:55
(8) кто не содержит собственную армию - тот содержит чужую (с)
13 VladZ
 
14.06.18
10:56
(3) Я бы не стал. А потом встанет вопрос: а кто будет тестировать программу для тестирования?

Лучше уж пусть человек сядет и потычет.
14 Вафель
 
14.06.18
11:00
(8) нужно регрисионные тесты просто делать,тогда ломаться будет на пару порядокв меньше
15 like
 
14.06.18
11:01
Вау, как быстро....
Давайте уточню, про производительность не шла речь, это отдельный вопрос, при котором на тестирование на "реальных данных" обязательное условие - ИМХО
16 Остап Сулейманович
 
14.06.18
11:05
(14) Тест - это просто тест. Любой. Хоть даже и регрессионный (правда я не понял к чему оно((( ). Оно от "поломок" не защитит. Тест поможет выявить логическую ошибку.
Но! Как сказал ТС - только на конкретном наборе тестовых данных. Отсутствие ошибок на одном наборе абсолютно не означает их отсутствие на другом наборе.
Вот ТС и пытается понять - какое количество наборов нужно для более менее достоверного тестирования. И кто эти наборы будет готовить.
Как то так.
17 МихаилМ
 
14.06.18
11:06
база 500 гб - можно каждому разрабу позволить присовременых ценах на хдд.
18 like
 
14.06.18
11:06
(16) Именно, спасибо вам
19 like
 
14.06.18
11:07
(17) Это больше похоже на мечты, потому что таких проектов может быть больше одного
20 Джинн
 
14.06.18
11:08
Что за тупой вопрос? Моделируется ситуация и тестируется. С вводом данных. По возможности применяю метод, принятый в ВВС США - модель должна быть такая, что проверяются все существующие ветки алгоритма.
21 like
 
14.06.18
11:08
(16) И еще дополнение как эти наборы будут создаваться, ввиду того что в платформе слой данных не отделен от слоя логики
22 like
 
14.06.18
11:08
(20) Вы часто это делаете?
23 shuhard
 
14.06.18
11:11
(21)[ввиду того что в платформе слой данных не отделен от слоя логики]
очевидный бред
24 ptiz
 
14.06.18
11:13
(19) Без копии реальной базы, пускай не с последними данными - никуда. Раз в неделю восстанавливать копию рабочей, накатывать на неё все наработки, на ней и тестировать. Если не каждому разрабу, то по копии на каждые 5 человек. Ненужные данные ради уменьшения объема можно и прямыми запросами удалить.
25 like
 
14.06.18
11:13
(23) Правда?? Я аргументирую, невозможно создать и записать объект предметной области в имитацию бд (речь про бд в памяти)
26 like
 
14.06.18
11:15
(24) Ну то есть в течении недели вы не совсем понимаете можете ли вы выпустить релиз сейчас или нет? Это не упрек, я правда пытаюсь понять как обстоят дела у "других"
27 Вафель
 
14.06.18
11:15
(16) тестиирование не защищает на 100%, а уменьшает количество ошибок
28 Вафель
 
14.06.18
11:16
(20) Это называется 100% покрытие кода тестами
29 Mort
 
14.06.18
11:17
80% кода будут работать если ты просто один раз взял, запустил и оно работает.

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

Тестирование вскрывает только очевидные косяки.
30 like
 
14.06.18
11:17
(27) бесспорно, но мне кажется мы все таки удаляемся от основного вопроса, он звучит так: "Как вы тестируете свой код"
31 BeerHelpsMeWin
 
14.06.18
11:18
А можно узнать, что это за контора, где есть 20 разработчиков, но нет возможности развернуть тестовую, пусть и 500гб базу заказчика? И зачем вы беретесь за такие проекты?
32 ptiz
 
14.06.18
11:18
(26) А зачем обновляться чаще раза в неделю? Что за жареный петух вас клюет? Или "хренась-хренась и в продакшен"?
Имхо, если 20 человек пилят одну базу - частые обновления приведут к хаосу. Должно быть время на "вылизывание" релиза перед накатыванием в рабочую базу.
33 Вафель
 
14.06.18
11:18
(30) лично я пишу тесты
34 like
 
14.06.18
11:19
(29) В моем понимании тестирование это набор "шишок" которые мы набили ранее и будем стараться не допускать в будущем, увы память (человечекая) для хранения всех этих "шишок" с моей точки зрения для этого не подходит
35 Вафель
 
14.06.18
11:19
Например такие
https://github.com/a-sitnikov/erp2_xtests
36 Diman000
 
14.06.18
11:20
Если ситуация сложная, то как тестировать надо думать заранее.
И почему это базу в 500 Гб дублировать для целей тестирования это не вариант?
У меня, например, есть такой вариант построения тестового контура.
Одна база является полной копией рабочей, каждую ночь копируется. Это для всяких экспериментов над продуктивом и реальными данными, для воспроизведения ошибок в продуктиве и все такое.
Вторая база также каждую ночь поднимается из рабочей, а утром в нее накатывают конфигурацию из хранилища разработки. Это получается база для тестирования алгоритмов разработки на актуальных данных.
В третью базу тоже ежедневно загружается конфигурация разработки, то актуальными данными она автоматически не обновляется, только по запросу. Это чтобы долговременные тестовые примеры не затирались.

И да, рабочая база у нас как раз 500гб. Но вот ее тестовые копии 100-150, потому как из них версии удаляем и саму базу сжимаем.
У каждого программиста база с данными и по запросу она актуализируется свежей копией.
37 like
 
14.06.18
11:20
(32) Этого жаренного петуха обычно называют критический релиз
38 Вафель
 
14.06.18
11:20
Ну и вооще континуус интегрэйшн придумали уже давно
39 zak555
 
14.06.18
11:20
> Думаю все понимают что это не вариант…

почему не вариант ?
40 фросия
 
14.06.18
11:21
есть такая профессия: тестировщик
41 Вафель
 
14.06.18
11:22
(40) у вас тестировщик тесты пишет или ручками прокликивает?
42 очко
 
14.06.18
11:24
(35) А ты можешь видос записать и на ютуб выложить как ты это делаешь?
43 Mort
 
14.06.18
11:24
(34) Тестирование это хорошо, когда помещаешь релиз и вдруг оказывается, что форма заказа тупо не открывается - тупо две команды написали противоречащий код.
Правило Паретто, 20% усилий дают 80% результата. Тестирование вот и должно давать 80% результата за мелкие усилия. Простая обработка которая прогонит важные формы и объекты. Гнаться за 100%, называя это покрытием кода или ещё какой глупостью, имхо, не надо. Надо усилия в другом месте приложить - толку будет больше.
44 shuhard
 
14.06.18
11:27
(25) [невозможно создать и записать объект предметной области в имитацию бд (речь про бд в памяти)]
начните с азов, отличия неймановской и принстонской архитектур
45 Numerus Mikhail
 
14.06.18
11:27
(0) выпускаем отраслевое решение для 50+ филиалов по России
Есть копии почти всех баз.
После разработки тестируется на нескольких самых больших базах. Раз в 3 месяца выпускается бета релиз, регионы уже сами тестируют, если хотят. После этого выпускается нормальный релиз.
46 фросия
 
14.06.18
11:28
(41) я не знаю ни одного тестировщика, пожтому не могу сказать как они работают
47 Mort
 
14.06.18
11:29
Конечно, тестирование в последнее время используют в качестве формализации задачи на мид- и микро- уровне. Даже название дали "TDD". Код, который, написан под формализованной задачей в виде проходимого теста качественее, чем код написанный от балды по ТЗ без цели, это да. А к тестированию в классическом пониманию как к проверке готового продукта это мало имеет отношения имхо.
48 очко
 
14.06.18
11:31
А кто-нибудь юзал 1С:Сценарное тестирование?
49 ildary
 
14.06.18
11:41
(42) я бы тоже посмотрел такое видео, т.к. хочется освоить автотесты, надоело руками тестировать.
50 like
 
14.06.18
11:43
(48) юзали, очень не удобно, не надёжные в плане выполнения, отваливаются по не понятным причинам, спасает перезапуск
51 like
 
14.06.18
11:45
А кто нибудь реально юнит тестами пользовался? Интересует вопрос с большими запросами, опять таки где и как хранить тестовые наборы
52 like
 
14.06.18
11:48
(45) спасибо, ознакомился
53 Cyberhawk
 
14.06.18
11:48
Иногда настраиваю автоматическую миграцию данных из рабочей инфобазы (или ее копии) в ЦТБ (центральную тестовую базу)
54 Cyberhawk
 
14.06.18
11:48
Это закрывает вопрос об имении актуальных реальных данных у разработчиков
55 Cyberhawk
 
14.06.18
11:49
И это явно более выгодный вариант, чем делать копию рабочей и на нее накатывать изменения из текущего хранилища" разработки
56 Aleksey
 
14.06.18
12:02
Даже 1с не позволяет себе на 100% тестировать свой продукт.
57 Aleksey
 
14.06.18
12:08
А так у 1с есть статья по этому поводу. Она рекомендует по мимо рабочего сервера (сервер заказчика с реальными данными) иметь еще 3 промежуточных сервера: сервер разработчика (с тестовыми данными), сервер тестирования (тестовые данные) и подготовительный сервер (с пользовательскими данными). Т.е. не нужно каждому разработчику давать реальную базу

Источник https://its.1c.ru/db/metod8dev#content:5905:hdoc
58 4St
 
14.06.18
12:11
(51) Тестовые наборы можно готовить через xUnitFor1C
https://github.com/xDrivenDevelopment/xUnitFor1C/wiki/Тестирование-через-образец-исходных-данных
Пользуемся иногда. Вполне себе работающий механизм.
А против (43) еще помогает практика code review. Прямо сильно помогает.
59 shuhard
 
14.06.18
12:12
(57) великое открытие на 30 году существования вендора
dev
uat
test
60 Aleksey
 
14.06.18
12:28
(59) Зная код типовых и как иногда 1с относиться к своим же рекомендациям, то сдается мне что знание и использование это разные вещи
61 Вафель
 
14.06.18
12:30
(58) только вот код ревью должен быть всегда, а не выборочно
62 Cyberhawk
 
14.06.18
12:33
(61) А кто его (по феншую) должен осуществлять? Напарник (параллельно к тебе в должности) или какой-нибудь вышестоящий гуру?
63 Вафель
 
14.06.18
12:39
(62) тимлид
64 like
 
14.06.18
12:40
спасибо всем, я в принципе получил ответы на свои вопросы
65 KAUTERPER
 
14.06.18
12:42
Нет проблем. Напрягаешься и сразу пишешь божественный код, который не нужно тестировать.
66 DrShad
 
14.06.18
12:53
(64) ТЗ естественно нет?
67 like
 
14.06.18
12:57
(66) больше чем тз, обследование и тех проект есть, но только это не решает вопрос удобства тестирования
68 DrShad
 
14.06.18
13:21
(67) обследование и тех проект это больше чем ТЗ!? не смешите
69 4St
 
14.06.18
16:50
(61) (62) (63)да, ревью должны быть постоянными. Очень помогает чек лист: проверяем форматирование, разыменования в запросах, осмысленность имён переменных и методов, возможность завершения циклов и и тд. Если есть разногласия по пунктам не из чеклиста, решаем по ситуации. Главное - даже не догма, а здравый смысл.
Тимлидов на весь код не хватает, простые вещи спокойно проверяют мидлы. Плюс появляются общие стандарты кода и общее владение кодом, копипасты меньше.
Минус - это небольшое удорожание разработки. Плюс - не так страшно на продакшн выкладывать, техподдержке легче, и продукт не так быстро становится горой костылей.
Одно только понимание, что твой код будут читать, заставляет писать по человечески. Особенно когда с этими читателями вместе обедать ходишь.
70 Вафель
 
14.06.18
17:57
(69) через гит ревью делаете?
71 exwill
 
14.06.18
17:58
(0) Математически доказано, что эта проблема не решаема. Поэтому. Написал код. Отдал заказчику. Работает? Ну и ладно.
Не работает? Исправляешь.
Можно и потестировать перед передачей заказчику. Но увлекаться не надо. Потому что надежного результата ты все равно не получишь.
72 4St
 
14.06.18
18:11
(70) когда как. Чаще всего все-таки через конфигуратор, там удобнее навигация по коду. Результаты фиксируем в рамках тикета на разработку в jira или gitlab.
В вебе гитлаба иногда смотрим blame, если надо быстро понять, кто это накодил. Гитовый клиент у нас sourcetree, там тоже мельком посматриваем, кто над чем работает в данный момент, какие новости в коде, где предстоит тяжёлый мерж и и.д.
73 Вафель
 
14.06.18
18:26
(72) но ведь сравнение версий в конфигураторе - это потеря полчаса времени
74 4St
 
14.06.18
18:39
(73) нам проще, пишем внешние обработки. Там порядка 100 000 строк кода и от 50 до 130 форм, но конфигуратор это пережевывает, понятно, быстрее, чем соседние релизы erp.
Зато с ветками удобно, и объединять интереснее.
75 dmpl
 
15.06.18
08:49
(0) Тестовый набор данных подписывается у заказчика как часть ТЗ. Если на них работает - значит продукт написан качественно, подписывается акт, получаются деньги.
76 dmpl
 
15.06.18
08:54
(37) Подождут.
77 dmpl
 
15.06.18
09:00
(73) От объема изменений зависит. Бывает и 1-2 минуты.
78 luter-89
 
15.06.18
09:40
Нужно писать код так, чтобы он не зависел от входных данных, обрабатывать все возможные типы данных, тогда и ошибок не будет.
79 Dotoshin
 
15.06.18
10:21
(78) Ты недооцениваешь способности пользователей. Иногда они изобретают такие комбинации данных, которые тебе сроду в голову не придут. Так что все возможные варианты не предусмотришь. Поэтому пишутся тест-кейсы, в в которых предусмотрены определенные наборы данных и по этим кейсам  тестится разработанное ПО. Если в рамках кейса косяков нет, то считаем что ошибок нет. Но на самом деле ошибки все равно есть, просто они пока еще не проявились.
Бывает так, что ошибки проявляются только при каких-то определенных обстоятельствах. Например на разных компах,  на одном и том же наборе данных, на одном компе ошибка есть, а на другом нет. Недавно боролись с масштабированием УФ, на одном компе все масштабируется, а на другом нет. Оказалось, что на одном компе стояли не все обновления или как-то криво стояли. В общем сделали все одинаково, все заработало.
80 Cyberhawk
 
15.06.18
10:40
"все возможные варианты не предусмотришь" // Дарю: "иначе"
81 Cyberhawk
 
15.06.18
10:41
+(80) "Иначе ВызватьИсключение "Неождаемое поведение, ололо, разбирайся""
82 Cyberhawk
 
15.06.18
10:42
"Бывает так, что ошибки проявляются только при каких-то определенных обстоятельствах. Например на разных компах" // Ага, с разными версиями Андроида и мобильной платформы 1С это особенно наглядно проявляется - цирк еще тот
83 ildary
 
15.06.18
11:15
(82) с разными версиями пользователей особенно.
Я не хочу быть самым богатым человеком на кладбище. Засыпать с чувством, что за день я сделал какую-нибудь потрясающую вещь — вот что меня интересует. Стив Джобс