Вход | Регистрация
    1  2  3  4  5   
1С:Предприятие :: 1С:Предприятие 8 общая

Будет ли в 1С настоящая TDD?

Будет ли в 1С настоящая TDD?
Я
   Конструктор1С
 
03.10.20 - 08:58
TDD (Test Driven Development, то есть "разработка через тестирование"). Очень популярная в тру-программировании концепция, позволяющая серьёзно повысить производительность труда программистов. В 1с инструментов для этого пока что нет, но тут виной скорее концептуальные особенности 1с. Если в той же Java есть возможность протестировать отдельный класс сам по себе, то в 1с так не сделаешь, за редким исключением (например, несложные экспортные методы общих модулей).
Да, есть такие штуки, как xUnitFor1C, Vanessa-behavoir и иже с ними. Но это скорее BDD, которое хоть и принято считать ответвлением TDD, но по сути таковым не является.

Суть TDD: модульные тесты должны писаться заранее, еще до написания кода продукта (разработка ЧЕРЕЗ тестирование). Т.е. кода (метода, например) ещё нет, а тест под будущий код уже есть. Р.Мартин выделяет три закона TDD:
"Первый закон. Не пишите код продукта, пока не напишете отказной модульный тест.
Второй закон. Не пишите модульный тест в объеме большем, чем необходимо для отказа. Невозможность компиляции является отказом.
Третий закон. Не пишите код продукта в объем большем, чем необходимо для прохождения текущего отказного теста.
Эти три закона устанавливают рамки рабочего цикла, длительность которого составляет, вероятно, около 30 секунд. Тесты и код продукта пишутся вместе, а тесты на несколько секунд опережают код продукта. При такой организации работы мы пишем десятки тестов ежедневно, сотни тестов ежемесячно, тысячи тестов ежегодно. При такой организации работы тесты охватывают практически все аспекты кода продукта" (с)

По-моему уже понятно, что все эти ванессы-шманессы ни разу не TDD, и TDD как такового в 1с нет. xUnitFor1C ещё как-то что-то похожее, но полноценным TDD там и не пахнет. Кто что думает, появятся ли для 1с удобные утилиты, позволяющие полноценно разрабатывать с применением TDD?
   NorthWind
 
1 - 03.10.20 - 09:09
30 секунд - это что имеется в виду и что за 30 секунд можно написать? Я вот эту фразу примерно столько пишу, может, чуть меньше.
   Конструктор1С
 
2 - 03.10.20 - 09:17
(1) это по-мартиновски 30 секунд. Роберт Мартин призывает писать коротенькие методы (на Java по крайней мере), чтобы один метод составлял 2-6 строк. Маленькие компактненькие методы. Наверно поэтому такой короткий интервал времени он берёт. Маленький тестик метода, маленький метод, маленький тестик метода, маленький метод... Но это моё предположение. Может просто неточность/ошибочность перевода, и на самом деле там не секунды, а минуты
   ДенисЧ
 
3 - 03.10.20 - 09:22
Маленькие компактненькие...
Где-то это я уже видел... А, точно. В БСП. С вложенностью стека на 60-70
   Стаканов
 
4 - 03.10.20 - 09:24
(0) Когда будет значительное число проектов "с нуля", а не перепилки типовых - тогда может это будет иметь смысл. А так - ну чисто 1С-никам почувствовать себя настоящими программистами :))
   Конструктор1С
 
5 - 03.10.20 - 09:25
А не, перевод нормальный. В оригинале
These three laws lock you into a cycle that is perhaps thirty seconds long. The tests and the production code are written together, with the tests just a few seconds ahead of the production code
   Конструктор1С
 
6 - 03.10.20 - 09:26
(3) а чем тебе вложенность стека не угодила?
   Конструктор1С
 
7 - 03.10.20 - 09:29
(4) TDD не делит разработки на маленькие и большие, с нуля и не с нуля. Под TDD можно разрабатывать хоть 100 строк кода с нуля, хоть 100.000 строк кода для существующей системы
   ДенисЧ
 
8 - 03.10.20 - 09:32
(6) Я комплексую, когда у 1с длиннее, чем у меня )))
   Конструктор1С
 
9 - 03.10.20 - 09:33
(8) сделай у себя длиннее)
   BeerHelpsMeWin
 
10 - 03.10.20 - 09:38
(0) а чем тогда пользователи на продакшне будут заниматься вместо тестирования?
   BeerHelpsMeWin
 
11 - 03.10.20 - 09:39
Ну и для начала TDD было бы неплохо заняться самой компании 1С на типовых конфах.
   NorthWind
 
12 - 03.10.20 - 09:58
(2),(5) а там примеров нет? Идеализм какой-то. Против коротких методов я ничего не имею, но.
Во-первых, есть разделение алгоритма на отдельные блоки. Если я выношу логический блок в метод и у меня получается минимум 8-10 строк, а не 6 - это я дурак? Или все же нет?
Во-вторых, даже пять строк можно тестировать и отлаживать больше 30 секунд.
Что-то здесь не то.
   Стаканов
 
13 - 03.10.20 - 09:58
(7) Ну так на код от 1С нет покрытия, а за то, чтобы было, никто платить не будет.
   Asmody
 
14 - 03.10.20 - 09:59
TDD – это порочный подход. Уже много раз обсуждено, не хочу повторяться.
   trdm
 
15 - 03.10.20 - 10:07
(0) > Очень популярная в тру-программировании концепция, позволяющая серьёзно повысить производительность труда программистов.

Тут как раз наоборот, производительность снижается, но повышается стабильность кода.
Кто тебе речь писал? :) Филолог? :)
   mistеr
 
16 - 03.10.20 - 10:10
(0) Для TDD нужна хорошая модульность. В частности, возможность создания моков для любых объектов, в т.ч встроенных. Не думаю, что 1С будет прилагать большие усилия в этом направлении. Это не выгодно фирме 1С. Почему? Сейчас платформа 1С это монолит, который если ты решил использовать, то нужно использовать по-полной. Или не использовать совсем. Все компоненты платформы, такие как объекты метаданных (ORM), средства разработки форм (GUI toolkit), средства разработки отчетов (СКД) и т.д. неразрывно связаны между собой. Ты не можешь, к примеру, взять стороннюю библиотеку для доступа к данным и привязать ее объекты к элементам на форме, или использовать сторонний менеджер блокировок вместо встроенного. Или хранить документы и справочники в какой-нибудь NoSQL базе данных. Это классический бандлинг (https://en.wikipedia.org/wiki/Product_bundling#Software)

Не секрет, что у 1С не Google и не Microsoft, у нее недостаточно ресурсов, чтобы сделать все компоненты платформы лучшими в своем классе или хотя бы не уровне лучших. Это компенсируется бандлингом.

Если улучшить модульность платформы, появятся возможности для анбандлинга, то есть разборки платформы. Разборка снизит конкурентные преимущества отдельных частей. Попытки анбандлинга и сейчас предпринимаются (metadata.js и прочие), и думаю, 1С наблюдает за ними с большой тревогой.

По той же причине я не ожидаю развития языка 1С в сторону улучшения ООП.
   Конструктор1С
 
17 - 03.10.20 - 10:11
(12) там много примеров. В двух словах не описать. Если интересно, прочти книгу (есть в электронном варианте):
ozon.ru/context/detail/id/5011068/
   trdm
 
18 - 03.10.20 - 10:16
ИМХО 1С-у TDD нужен в редких случаях.
Это же не файловая система или менеджер памяти.
Тут многое проще.
   Конструктор1С
 
19 - 03.10.20 - 10:17
(14) например?
   trdm
 
20 - 03.10.20 - 10:22
(19) Тестировать алгоритмы проведения документов. они многоветвисты и сложны.
вот тут TDD может хорошо помочь.
у меня был модуль, который не TDD, а проще: запоминаются движ.доков, проводятся, сравниваются.
очень помогало.
   Конструктор1С
 
21 - 03.10.20 - 10:24
+(19) критикую всё. Критикуют ООП, критикуют windows, критикуют 1с. Нопочему-то они остаются очень популярными, а часто и самыми эффективными. Хотелось бы убедится, что хоронители TDD это не типичные критиканы, главная цель которых покритиковать
   Aleksey
 
22 - 03.10.20 - 10:29
(21) Ну как бы сколько лет TDD, лет 20? А оа почему то выстрелила не так сильно
   trdm
 
23 - 03.10.20 - 10:29
(21) ну, сигареты и прочая наркота тоже популярны.
не стоит мерить правильность популярностью :)
   Конструктор1С
 
24 - 03.10.20 - 10:30
(20) сложность тестирования проведения документов скорее упирается в концепции платформы 1с. Да всё TDD упирается в это. Процедура Хуяк(), а за ней алгоритм на 10 тыщ строк кода в модуле менеджера, и единственный способ постучатся к этому коду процедура Хуяк(), до отдельных участков алгоритма не достучаться. Есть, конечно, способы как это обойти, но это всё из разряда дрочерства: делать многие процедуры экспортными, например.
   Конструктор1С
 
25 - 03.10.20 - 10:32
(23) ничего общего с сигаретами у методик работы нет. TDD используют чтобы повысить производительность своего труда, качество продукта, а не из-за наркотической зависимости) Если бы TDD был неэффективным, он не был бы популярным
   Aleksey
 
26 - 03.10.20 - 10:33
(24) И не только. Время разработки вырастает процентов на 25%, при этом количество ошибок уменьшается где то на 40%. При условии что нужно было еще вчера выпустить релиз, то невыгодно
   Aleksey
 
27 - 03.10.20 - 10:34
(25) каким местом "TDD используют чтобы повысить производительность своего труда" - что за бред?
   PR
 
28 - 03.10.20 - 10:36
(0) Нахрена тебе в 1С TDD? И как ты это себе представляешь?
   МимохожийОднако
 
29 - 03.10.20 - 10:36
ОФФ: Автору стоит устроиться на работу в 1С. У него еще много задумок осталось. ))
   Конструктор1С
 
30 - 03.10.20 - 10:39
(27) здрасьте-приехали. Неужели программисту нужно объяснять, как автоматизированное тестирование повышает скорость разработки?
 
 Рекламное место пустует
   Aleksey
 
31 - 03.10.20 - 10:42
(30) какое отношение автоматизированное тестирование имеет к TDD?
   Конструктор1С
 
32 - 03.10.20 - 10:44
(31) кхм... Стесняюсь спросить, а что такое по-твоему TDD?
   PR
 
33 - 03.10.20 - 10:44
TDD — это тупиковый путь
Написал миллион тестов, отдал разработчику, тот сделал какого-то отвратительного франкенштейна, но по тестам все тютелька в тютельку, ни одной ошибки

TDD на примере разработки калькулятора
Сделали тесты, что 5 + 5 = 10, 5 - 5 = 0, 5 * 5 = 25, 5 / 5 = 1
Отдали разработчику
Тот сделал калькулятор, который верно вычисляет выражения 5 + 5, 5 - 5, 5 * 5 и 5 / 5, то есть тесты полностью проходят
А вот если попробовать на нем посчитать 2 + 2, то будет не 4, а, например, 10
Почему?
Ну тут же плюс в выражении, как и в 5 + 5, значит должно быть 10
А 5 + 3 - 2 вообще будет равно нулю, потому что такое описано в тестах не было и хрен его знает, как здесь считать

И кто после этого дебил?
   PR
 
34 - 03.10.20 - 10:45
(31) Да вроде как непосредственное
А вы с какой целью интересуетесь? :))
   Конструктор1С
 
35 - 03.10.20 - 10:48
(33) TDD так не применяют. При TDD разработчик сам пишет тесты для своего же кода. В твоём примере вопрос адекватности тестов (или покрытия тестами), а не в методике тестирования. На такой косяк можно наткнуться при любой другой методике тестирования, если покрытие кода будет недостаточным
   Aleksey
 
36 - 03.10.20 - 10:54
(34) Тут 2 сценария.
1. Пишем код программы, вручную проводим какие-нибудь тесты и лишь затем пишем автоматизированные тесты для имитации различных ситуаций. Имея надлежащие тесты можно свободно переходить к следующей фиче или провести рефакторинг, не боясь что-нибудь сломать. Мне кажется что это явно не TDD

2. Придумали фичу и функцию, написали тесты , далее работаем над функции, но понимаем что исходя из наших потребностях тесты не видят нашу функцию - переписали тест. Далее в процессе работы обнаружили, что непонятно как функция будет взаимодействовать с остальной системой. Немного переписав функцию мы закончили работать, и тут замечаем, что 1) наша функция была полностью написана и что 2) тест провалился.
   Aleksey
 
37 - 03.10.20 - 10:55
(35) И как это ускоряет разработку?
   PR
 
38 - 03.10.20 - 10:56
(35) Практика показывает, что программист пишет те тесты, которые, как правило, не имеют никакого отношения к реальной деятельности пользователей
Зато те тесты, которые нужно писать, программист не пишет
В итоге получается много, дорого и богато, зато бесполезно
   PR
 
39 - 03.10.20 - 10:58
(35) На такой косяк при BDD ты не наткнешься а принципе, потому что разработчик пишет код не отталкиваясь от тестов, а отталкиваясь от поставленной задачи
   PR
 
40 - 03.10.20 - 10:59
Уверен, что в 1С TDD дальше отладки и Сообщить() не пойдет
   Aleksey
 
41 - 03.10.20 - 11:00
Что хорошего в TDD- так это идея. Сначала сесть подумать, потом писать код, а не как обычно сначала пишут код, а потом думают, зачем  он тут нужен и где его можно применить (не удалять же такой красивый код)
   Answer42
 
42 - 03.10.20 - 11:06
(0) Не будет, конечно. "Настоящее" TDD с идеями типа давайте напишем тест на вызов несуществующего метода не применимо ни где, кроме smalltalk'а для которого его и придумали.

>Сначала сесть подумать, потом писать код, а не как обычно сначала пишут код
Это не так.
Идея "настоящего" TDD в том чтобы сначала также "бездумно" (как обычно код) писать тесты.
А сначала сесть и подумать - это водопад и вообще ретроградство.
   PR
 
43 - 03.10.20 - 11:08
(42) А что, в скраме думать не надо? O_o
   Aleksey
 
44 - 03.10.20 - 11:12
(42) Ты не сможешь бездумно написать код, если даже не понимаешь что тестировать и какие у тебя данные на входе и выходе. Т.е. хотя бы в общих чертах представляешь весь процесс. И тут как раз и будет первая засада. Потому что ленивые жопы пишут тест исходя из нормально работающей системой с предсказуемыми множествами данных (пример в (33))
   Конструктор1С
 
45 - 03.10.20 - 11:12
(37) количество ошибок, доделок-переделок существенно уменьшается, например. К тому же, TDD неплохо дисциплинирует. Ты следишь за тем, чтобы API твоих алгоритмов был как можно компактнее. Без тестирования кода херакнул процедуру, получающую в параметрах структуру с 50 ключами, и пошел дальше. Но когда ты сразу разрабатываешь тест кода, так писать код уже не будешь. Чтобы тест не превратился в зловещий ребус, тебе нужно сделать процедуру такой, чтобы на входе она получала как можно меньше легкоконтролируемых параметров. Это очень важно. Такой код намного гибче, в будущем его будет легче дорабатывать, что уже является повышением производительности
   Aleksey
 
46 - 03.10.20 - 11:16
"Но когда ты сразу разрабатываешь тест кода, так писать код уже не будешь" - почему?
Ну будет вместо 50 параметра 1 параметр с типом структуры в котором я могу безболезненно запихнуть еще 100500 параметров и тесты не будут на это реагировать, так как они ничего о них не знают. А так в случае добавления 51 параметрах у меня тесты сразу провалятся, так как не совпадает количество параметров
   PR
 
47 - 03.10.20 - 11:17
(45) Да всем посрать, сколько у тебя параметров в процедуре
Люди напишут BDD, который прогонит цикл ключевых операций, твой говнокод свалится и, ты не поверишь, кому на голову упадет все то дерьмо, которое ты подкинул в воздух
Так что программисты с IQ выше 40 пишут сразу читабельный максимально простой код не потому что так проще, а потому что делают это ради самих себя же
   Конструктор1С
 
48 - 03.10.20 - 11:18
(38) это уже вопрос квалификации программиста, а не тестирования как такового
   Aleksey
 
49 - 03.10.20 - 11:18
И чем проще писать код если структура, а не отдельный параметр?
   Aleksey
 
50 - 03.10.20 - 11:20
(48) И мы приходим к еще одной глобальнгой проблеме TDD - отсутствия культуры тестирования. Зачастую даже не понятно что и зачем тестировать
   PR
 
51 - 03.10.20 - 11:23
(48) Что за бред?
Еще раз
TDD — это когда сначала написали в тестах, как должно работать, и потом прогер делает так, чтобы работали тесты
BDD — это когда сначала прогеру говорят человеческим языком, как должно работать, и потом прогер делает так, чтобы работали тесты
В первом случае при разработке прогер _уже_ знает тесты, во-втором случае узнает их только после того, как его говнокод где-то начнет валиться
И, что важно, во-втором случае тесты наращиваются по мере появления новых ошибок
   Конструктор1С
 
52 - 03.10.20 - 11:27
(46) чтобы тестирование было удобным и надежным, сигнатура метода должна быть минимальной. Например

Функция СледующийРабочийДень(Дата)

такую функцию тестировать легко. Подал на вход несколько дат, и проверил что функция возвращает

Процедура РассчитатьНекуюХрень(Парам1,Парам2,Парам3,Парам4,Парам5,Парам6,Парам7,Парам8,Парам9,Парам10)

такую процедуру протестировать очень сложно. Тест получится просто зашкварный. Представляешь сколько вариаций вызова такой процедуры потребуется? Когда ты заранее знаешь, что тебе нужно будет писать тест для этого кода, ты не будешь городить такую сложноту
   Конструктор1С
 
53 - 03.10.20 - 11:28
(49) это не вопрос 10 параметров в методе, или одного параметра типа структура с 10 ключами. Это вопрос реорганизации кода так, чтобы он принимал 2 параметра простого типа
   Aleksey
 
54 - 03.10.20 - 11:28
(52) мы точно говорим о случаях сложнее чем Привет, Мир!?
Любая бизнес логика подразумевает кучу параметров
   PR
 
55 - 03.10.20 - 11:29
(52) А зачем мне как пользователю тестировать результат функции РассчитатьНекуюХрень?
Что это за функция?
Вызывается ли она где-нибудь хоть раз?
Что такое функция вообще?
Что полезного мне даст информация о том, работает эта функция правильно или нет?
Нахрена мне все это?
   Aleksey
 
56 - 03.10.20 - 11:29
Хорошо как написать функцию получения цены товара в УТ11 используя 1 параметр
   Aleksey
 
57 - 03.10.20 - 11:32
а главное какой тест мне написать, чтобы проверить что функция возвращает правильное значение?
   Конструктор1С
 
58 - 03.10.20 - 11:33
(51) чувак, TDD это совсем не про то. При TDD тесты пишет сам программист, а не сторонний Вася.

Нужно мне написать функцию СледующийРабочийДень. Первым делом я пишу тесты, которые проверят эту функцию:

СледующийРабочийДень(03.10.2020) = 05.10.2020
СледующийРабочийДень(20.10.2020) = 21.10.2020
СледующийРабочийДень(31.12.2020) = 11.01.2021

и только после этого приступаю к реализации самой функции СледующийРабочийДень()
   mistеr
 
59 - 03.10.20 - 11:33
(55) Давайте спорить о вкусе устриц с теми, кто их ел. (с) М. Жванецкий
   PR
 
60 - 03.10.20 - 11:35
(58) Рукалицо
Вернись назад, прочитай ветку с начала, а то по второму кругу пошли

Про
СледующийРабочийДень(03.10.2020) = 05.10.2020
СледующийРабочийДень(20.10.2020) = 21.10.2020
СледующийРабочийДень(31.12.2020) = 11.01.2021
молчу, странные тесты
 
 Рекламное место пустует
   MadHead
 
61 - 03.10.20 - 11:35
Не будет. Язык вообще не позволяет писать юнит тесты.
   PR
 
62 - 03.10.20 - 11:35
(59) Эээ... ну давайте
Я ел
Ты ел?
   Конструктор1С
 
63 - 03.10.20 - 11:37
(54) разумеется, подразумевает кучу параметров. Но это именно вопрос организации кода, а не сложность бизнес-логики. Когда декомпозиция проработана, а методы работают по принципу: одно действие - один метод, то никаких зашкварных процедур с десятью входными параметрами просто не будет
   Конструктор1С
 
64 - 03.10.20 - 11:38
(60) как по-твоему тесты кода выглядят? Именно так код и тестируется. На вход определённые параметры, на выходе проверяется, соответствует ли результат ожидаемому
   Конструктор1С
 
65 - 03.10.20 - 11:39
(61) это да. Языковое ограничение существенное
   PR
 
66 - 03.10.20 - 11:40
(64) А, ты же про рабочие дни, ну ok
   Web00001
 
67 - 03.10.20 - 11:43
Тестирования не хватает конечно. У нас очень сложный механизм скидок с большим количеством вариантов. Билеты бонусы акции, сезонные скидки, скидки по волшебному слову, ну и тд. Каждый раз прикручиваешь новый механизм, думаю не сломаешь ли какой из старых. Но периодически, все таки, что-то ломаешь. И есть еще несколько моментов. Особенно, что касается прав, все время забываю раздавать права. Хорошо, бы перед вытаскиванием кода в боевую базу пробежали бы тесты, создали записали провели документы, под разными правами. Рассчитали скидки и тд.
   Конструктор1С
 
68 - 03.10.20 - 11:45
(66) а как ты представляешь себе тестирование кода? По-моему других способов пока не изобрели. Дёргаешь метод/класс с разными параметрами, и проверяешь, соответствует его работа ожидаемой или нет. Во многих языках даже есть специальные конструкции для проверки ожидаемого поведения - assert'ы
https://habr.com/ru/post/141080/
   Aleksey
 
69 - 03.10.20 - 11:45
(63) Действие одно получить цену
   PR
 
70 - 03.10.20 - 11:49
(68) Что значит как?
BDD
Сказал прогеру что сделать
Он сделал
Запускаешь Ванессу, нащелкал тест
Запустил тест, посмотрел, чтобы он не упал
   Конструктор1С
 
71 - 03.10.20 - 11:52
(69) действие в коде это не бизнес-действие. Рассчитать зарплату тоже одно действие, только под капотом десятки тысяч строк

Декомпозиция, есть такое слово
1. Рассчитать зарплату
1.1. Рассчитать неявки
1.2. Рассчитать повременную оплату
1.2.1. Получить норму по графику
1.2.2. Определить количество фактически отработанных дней
1.2.3. Получить оклад
...
1.3. рассчитать сдельную оплату
2. Рассчитать НДФЛ
3. Рассчитать страховые взносы

все эти действия могут быть гранулированы по-разному. Каждый напишет по-своему:
программист курильщика напишет здоровенные процедуры, с десятью входными параметрами
программист здорового человека выполнит декомпозицию и напишет компактные методы с простой сигнатурой входящих параметров
   PR
 
72 - 03.10.20 - 11:55
(71) Вот именно
И нахрена мне тест проверки функции ПолучитьДанныеРасчетаПоСпискуСотрудниковСОтсутствиямиИНачисленнымиИПеречисленнымиЗарплатнымиНалогами?
   Конструктор1С
 
73 - 03.10.20 - 11:55
(70) ты же понимаешь, что покрытие получается весьма поверхностное? Чтобы от и до проверить проведение одного тебе потребуется зашкварный тест, проводящий несколько сотен документов данного типа с различными значениями. Только по времени такой тест будет долго выполняться
   Aleksey
 
74 - 03.10.20 - 11:56
(71) Да что же ты как уж на сковородке вертишься. Конкретный пример, и ты не можешь его решить с помощью TDD
Или если пример не входит в логику TDD то это неправильный пример и его нужно игнорировать
   PR
 
75 - 03.10.20 - 12:01
(73) Да, конечно
И что?
Ты и в TDD исчерпывающий набор тестов не напишешь
Зато в BDD тесты полезные, понятные пользователю и наращиваемые
И заставляют прогера думать головой, а не писать "под тесты"
   Конструктор1С
 
76 - 03.10.20 - 12:02
(72) потому что гораздо надёжнее проверять поведение частей алгоритма, чем всего целиком. Ну запустил ты свой тест, проверил что запрлата посчиталась неправильно. Дальше что? Только лопатить код. А ошибка могла быть в какой-то одной несчастной функции, которая возвращала неправильное значение. Но чтобы найти эту функцию, тебе придётся пробежаться отладчиком через половину конфигурации. Такая вот разная локализация ошибок. Без мелких покрывающих тестовы ты будешь только знать, что у тебя что-то неправильно работает, но ещё не будешь знать, что конкретно неправильно работает. Для выяснения причин тебе потребуется много часов. А будь у тебя тест, покрывающий код, он сразу вывел бы тебя на эту функцию. Чувствуешь разницу?
   Конструктор1С
 
77 - 03.10.20 - 12:03
(74) твой пример прекрасно ложится под TDD. С чего ты взял, что тут TDD спасует?
   Aleksey
 
78 - 03.10.20 - 12:04
(77) так приведи как это реализовать с использованием процедуры с 1 параметром и поясни как тест проверит корректность полученных данных
   Конструктор1С
 
79 - 03.10.20 - 12:05
(75) "Ты и в TDD исчерпывающий набор тестов не напишешь"

Как раз-таки напишешь
   Aleksey
 
80 - 03.10.20 - 12:06
(79)
Ну вот у меня 12 тысяч позиций, 4 видов цен и все в разных валютах, как правильно написать тест чтобы он подтвердил корректность получения всех данных на любое число
   mistеr
 
81 - 03.10.20 - 12:08
(62) Ел. А вот ты не похоже, что ел.
   Конструктор1С
 
82 - 03.10.20 - 12:09
(78) всё просто. Одна процедура с десятью параметрами превращается в несколько процедур с двумя-тремя параметрами каждая. Все десять параметров тебе не нужны в один момент времени. Конечно, код может грести и все 10 параметров за раз. Но его легко реаргонизовать так, чтобы в один момент требовалось только пара параметров. В винде десятки миллионов строк кода, но вряд ли ты там найдёшь метод с сотянми параметров
   mistеr
 
83 - 03.10.20 - 12:11
(80) Нужно покрыть тест кейсами все основные случаи и желательно большинство крайних. И это гораздо меньше, чем 12000 * 4 * 3(валюты). Это 10-15 кейсов.

Ты же не доказываешь теорему Пифагора для отдельно дла каждого из возможных значений a, b и c.
   Конструктор1С
 
84 - 03.10.20 - 12:12
(80) твой алгоритм раскладывается на части. Тебе нужно по отдельности проверить:
1. Что курс валюты получается корректный
2. Что цена получается корректно
3. Что цена на курс перемножается корректно
...
для этого впринципе не обязательно пропускать все 12 тыщ позиций через тест. Декомпозируй и властвуй!
   Aleksey
 
85 - 03.10.20 - 12:14
(84) "Что цена получается корректно" - как? Описать все 12 тысяч * видцен* дату
Я не понимаю как написать тест, чтобы он проходил на любой базе и на любых данных
   Конструктор1С
 
86 - 03.10.20 - 12:16
(85) разумеется, нет. Достаточно проверить несколько позиций
   Aleksey
 
87 - 03.10.20 - 12:18
(86) что 
А. не гарантирует 100%
Б. не гарантирует что завтра этот тест пройдет, так как исходные данные в базе могут быть изменены, а значит завтра, когда я начну пилить бонусную программу, мои старые тесты будут неактуальны и я не могу гарантировать их корректность
   Конструктор1С
 
88 - 03.10.20 - 12:21
(87) если данные изменятся, тест сразу же выпадет в ошибку. И ты будешь знать, что появилась проблема именно в получении цены. Всё, вот она твоя ошибка, локализована. Тест сработал
   PR
 
89 - 03.10.20 - 12:33
(76) Рукалицо
Ладно, забей
   PR
 
90 - 03.10.20 - 12:34
(79) Клиника какая-то, упоротость 80-го уровня
   PR
 
91 - 03.10.20 - 12:35
(81) И что мне с твоих подозрений?
А мне непохоже, что ты ел
И что?
   PR
 
92 - 03.10.20 - 12:40
(88) А если все прекрасно проверилось, ошибок нет, а список контрагентов при выборе из списка почему-то пустой?
Что делать?
Где в твоих проверках неправильное использование правильно работающих процедур и функций?
   Конструктор1С
 
93 - 03.10.20 - 12:40
(90) что упоростость? Писать покрывающие код тесты? Так всё взрослое программирование делает. Только до 1с пока что не дошло
   Конструктор1С
 
94 - 03.10.20 - 12:47
(92) вот что ты такой нудный? Твоя ванесса тебе покажет, что документ стал неправильно проводиться. Всё. Дальше сам ищи проблему в 10 тысячах строк кода. А модульное тестирование сразу ткнёт пальцем, что вот эта сраная процедура перестала правильно работать. Модульное тестирование в любом случае копает намного глубже, чем ванесса. В иделае они должны дополнять друг друга
   mistеr
 
95 - 03.10.20 - 12:48
(94) Что документ перестал проводиться, это и пользователь может сказать. Ванесса не нужна для этого :)
   PR
 
96 - 03.10.20 - 12:50
(93) Упоротость в твоем игнорировании аргументов, которые я пишу
   Конструктор1С
 
97 - 03.10.20 - 12:57
(96) твои аргументы опираются на твоё непонимание TDD, да и вообще модульного тестирования
   PR
 
98 - 03.10.20 - 13:01
(94) Блеать! Ничто ничего не покажет, код идеально верный, ни единой синтаксической ошибки!
Но просто прогер вызвал идеально работающую функцию там, где ее не нужно было вызывать
Все!
Что будешь делать?
Рассказывать пользователю, что да пошел он в жопу со своими странными проблемами?
У тебя же твой код работает без ошибок, верно?

Еще раз
Главная цель тестирования — не дать коду, приводимому к ошибочному результату, попасть в прод
Ошибочному результату с точки зрения *пользователя*, а не *программиста*
Пользователю на проблемы программиста поссать с высокой колокольни
Если ты программист и хочешь сам себе написать сначала TDD, а потом уже ваять код (со вложенными в него TDD-тестами) — удачи, кто тебе запретит-то
Но это нихрена ни разу не отменяет твоей обязанности покрыть свое творчество BDD-тестами
Потому что именно BDD, а не TDD, понятно и близко пользователю, именно BDD, а не TDD, является тем, что сокращает количество визитов к тебя пользователей с битами и звонков недоумевающего охреневающего начальства
Если ты бессмертный упоротый индивид с IQ 40, продолжай использовать TDD без использования BDD, чо
   Конструктор1С
 
99 - 03.10.20 - 13:02
Давай попробуем на пальцах. Твоя машина перестала заводиться. Какая диагностика лучше: которая скажет "проблема под капотом", или которая укажет на конкретный агрегат автомобиля?
   PR
 
100 - 03.10.20 - 13:02
(95) Именно
Ванесса нужна для того, чтобы ты узнал о проблеме раньше пользователя, когда он тебе в дверь ногой постучит
  1  2  3  4  5   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.