Вход | Регистрация
    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?
   Конструктор1С
 
101 - 03.10.20 - 13:06
(98) "Главная цель тестирования — не дать коду, приводимому к ошибочному результату, попасть в прод"

Вот тут точно рука-лицо. Ну узнал ты, что твой автобус не заводится, не вывел его в рейс, и что? Впереди многодневная ебля по поиску причины помолки. Нормальное тестирование должно не просто констатировать, что автобус сломался, а указать что сломался конкретно стартер
   PR
 
102 - 03.10.20 - 13:06
(99) Та, которая скажет мне о проблеме на этапе производства
Только TDD в твоем случае — это нихрена не "проблема в конкретном агрегате"
TDD — это то, что твой пепелац соответствует изначально написанным техническим тестам
С какого хрена ты решил, что раз у тебя есть TDD, то это теперь ответ на любую ошибку, что проблема именно там-то и там-то, я в душе не подозреваю
   Конструктор1С
 
103 - 03.10.20 - 13:08
(100) модульное тестирование сделает это гораздо эффективнее. Не тупо скажет "в РТУ проблема" а скажет "проблема в РТУ в процедуре Хуяк()"
   PR
 
104 - 03.10.20 - 13:09
(101) А стартер, блеать, работает как часы, прикинь!
И вообще все работает как часы
Но автобус не едет
Что будешь делать?
   Конструктор1С
 
105 - 03.10.20 - 13:10
(102) ты всё-таки почитай про модульное тестирование
   PR
 
106 - 03.10.20 - 13:11
(103) Ты идиот что ли?
Я тебе говорю, я открываю список контрагентов, он пустой
TDD-тесты ничего не говорят
Что делать?

Еще раз, никто тебе не запрещает писать TDD-тесты, но пользователю они нахрен не нужны, ему нужны BDD-тесты
   PR
 
107 - 03.10.20 - 13:12
(105) Что именно мне почитать, раздел, в котором говорится, что TDD-тесты нужны, а BDD-тесты не нужны? Ссылка на такой текст дашь?
   Конструктор1С
 
108 - 03.10.20 - 13:14
(104) не фантазируй. Если диагностика проверяет конкретно стартер, и проверка показала проблему, то дело наверно в стартере
   Конструктор1С
 
109 - 03.10.20 - 13:15
(107) для начала просто выясни для себя, что такое TDD
   PR
 
110 - 03.10.20 - 13:16
(108) Так про стартер родила твоя фантазия
А на самом деле мышь погрызла проводку или ключ уронили и он перемкнул где-то цепь, в итоге каждый отдельный агрегат работает нормально, а автобус не едет
   PR
 
111 - 03.10.20 - 13:19
(109) Так вроде известно давно
Программисту говоря, напиши-ка такую-то процедуру/функцию, которая на таких-то тестах с такими-то входными параметрами пройдет без ошибок, то есть выдаст такой-то выходной результат
Прочитай уже (33) что ли
   Конструктор1С
 
112 - 03.10.20 - 13:21
(110) как всё запущено... Считай что диагностика снимает стартер, подаёт ток из гарантированного источника. В этом и суть модульного тестирования. Проверяется конкретный кусок кода без привязки к другим кускам кода.

ЗЫ проводку проверяет уже другой тест. Он её также снимает и подключает к источнику напряжения
   Конструктор1С
 
113 - 03.10.20 - 13:24
(111) заканчивай ты уже. Программист САМ пишет тест для проверки своей процедуры. Никто лучше программиста не знает, что и как должна делать процедура
   PR
 
114 - 03.10.20 - 13:25
(112) А ничего, что то, что ты описываешь, это 3 рубля на разработку автобуса и полмиллиона рублей на проверку всего, чего только можно?
А ничего, что проверка одного автобуса перед рейсом — это месяц работы целого автопарка, который будет все снимать, подключать на стенд, проверять, собирать обратно, комбинировать и т. д.?
   Конструктор1С
 
115 - 03.10.20 - 13:27
(114) а я тебе ещё раз говорю, читай что такое TDD. Там не то что нет дополнительных затрат, там экономия
   PR
 
116 - 03.10.20 - 13:32
(113) Да не важно, пусть сам пишет, главное не в этом, главное в разнице самих подходов
TDD-тесты проверяют на ошибки работу процедур/функций и понятны только программисту
BDD-тесты проверяют на ошибки пользовательский сценарий работы и понятны всем
   Конструктор1С
 
117 - 03.10.20 - 13:36
(116) между ними колоссальная разница в глубине диагностики
   PR
 
118 - 03.10.20 - 13:39
(117) И чо? К чему это? BDD-тесты нужны?
   Конструктор1С
 
119 - 03.10.20 - 13:51
(118) нужны, но не достаточны. Вот сломался у тебя ЗУП, расчет зарплаты не те цифры выдаёт. BDD указало на проблему. Ок, в прод косячный код не пустили. А дальше что? Брать в руки отладчик и привет долгим часам нудного поиска ошибки.  Через 30 часов нудной отладки ты выяснишь, что косячила одна процедура. А будь у тебя модульный тест, он эту косячную процедуру нашел бы за секунду
   ДенисЧ
 
120 - 03.10.20 - 13:53
Мдя.. Спорят двое... Один говорит, что небо синее, другой - что пиво не охладилось...
   PR
 
121 - 03.10.20 - 13:55
(119) Аллилуйя! BDD нужны!
На этом и остановимся
   Конструктор1С
 
122 - 03.10.20 - 13:58
(121) т.е ты весь топик поливал TDD только для того, чтобы констатировать нужность BDD?
   mistеr
 
123 - 03.10.20 - 14:16
Каждому человеку хочется ощущать себя правым хоть в чем-то.
Но некоторым этого мало. Им нужно кого-то другого, что тот неправ.
   mistеr
 
124 - 03.10.20 - 14:17
(123) нужно *убедить* кого-то
   PR
 
125 - 03.10.20 - 14:26
(122) Да нет, в (28) задал тебе вопрос, а ты его проигнорировал
А вопрос как раз подразумевал крайне небольшую ценность и чрезвычайно высокую трудоемкость TDD
И это при том, что в подавляющем большинстве случаев все прекрасно решается BDD
   Конструктор1С
 
126 - 03.10.20 - 15:37
(125) а с чего ты взял, что трудоёмкость высокая? Всё с точностью до наоборот, при грамотном применении TDD разработка идёт быстрее, чем без оной. И ценность у TDD очень высокая. Гораздо выше, чем у BDD
   Конструктор1С
 
127 - 03.10.20 - 15:43
Но ты не нов. Ещё лет пять назад 1сники наперебой кричали, мол нафига вообще это автоматизированное тестирование. Почему-то всё проходит через стадию отрицания и сопротивления
   PR
 
128 - 03.10.20 - 16:00
(126) Ценность небольшая, потому что обычно код на безошибочность проверяется один раз, в процессе его написания
Проверять постоянно, не перестала ли работать функция, которая еще вчера работала, достаточно странно
Это такая своеобразная гигиена, написал/поменял код — проверь его на безошибочность

Чрезвычайно высокая трудоемкость, потому что попробуй-ка встрой свои тесты в типовую
И даже в свой код встроить чрезвычайно тяжело
Легко, конечно же, покрыть тестами полностью функцию вычисления модуля числа
А ты попробуй покрой полностью тестами функцию расчета себестоимости партии товара

Приведешь реальный пример полезного кода, который нужно покрыть TDD-тестами, потому что там есть большие шансы, что что-нибудь сломается?
   PR
 
129 - 03.10.20 - 16:08
(127) Автоматизированное тестирование в 1С — это BDD, нахрена ты сейчас пытаешься натянуть сову на глобус, подменяя понятия?
Кто-то свой код даже в пользовательском режиме перед отдачей пользователю не проверяет, типа да ладно, и так сойдет
   Конструктор1С
 
130 - 03.10.20 - 16:11
(128) вот тут ты сиильно заблуждаешься. Код будет меняться снова и снова, раз за разом. Каждый раз изменения должны тестироваться. Надеюсь необходимость тестирования доказывать не нужно?

(129) так я про то и говорю, что лет пять назад 1сники плевались на BDD, примерно как ты сейчас плюёшься на модульное тестирование
 
 Рекламное место пустует
   PR
 
131 - 03.10.20 - 16:23
(130) Пример, дай пример, хватит софистики

То есть если пять лет назад кто-то плевал и на BDD и на, например, пидарасов, а сейчас на BDD перестал плевать, то неизбежно лет через пять жди нового пидараса?
Ммм, логика

Или ты увидел похожие буковки в TDD и BDD и на основании этого тут же сделал выводы о том, что их ждет идентичная судьба?
   Aleksey
 
132 - 03.10.20 - 16:28
(130) "Каждый раз изменения должны тестироваться" - для этого TDD и нафиг не нужен
   Конструктор1С
 
133 - 03.10.20 - 16:29
(131) нет, ты не понял. Как я уже неоднократно писал, 1сная отрасль отстаёт от взрослого программирования на 10-15-20 лет. В 1с только-только начали использовать автоматизированное тестирование, да и то пока что точечно, а во взрослом программировании автоматизированное тестирование на марше годов так с 90-х. Сейчас во взрослом программировании модульное тестирование (юнит-тестирование) это де-факто стандарт, им пользуются все уважающие себя компании и разработчики. Но ты, с приветом из 1сного отставания, кричишь о ненадобности модульного тестирования
   Конструктор1С
 
134 - 03.10.20 - 16:31
(132) а тесты после 2-3-5-10 изменения у тебя откуда должны появиться?
   Aleksey
 
135 - 03.10.20 - 16:31
(133) У тебя есть статистика? Взрослые люди говорят что во всем мире единицы используют TDD при разработки. Даже отцы основатели  TDD и то со временем признают частично ошибочность своих суждений
   Aleksey
 
136 - 03.10.20 - 16:31
(134) Из BDD
   PR
 
137 - 03.10.20 - 16:36
(133) Ладно, понятно, примера от тебя не получишь, только пистеть способен
   Aleksey
 
138 - 03.10.20 - 16:37
У меня есть задача выгрузить реквизиты контрагента в файл для загрузки его на сайт.
Т.е. на входе контрагент, на выходе текстовый документ.
В классическом программирование я должен взять выходной файл и проверить валидность данных (ну чтобы в поле почта была почта, а не телефон, а ИНН состоял как минимум из 10 цифр). В TDD я напишу тестирования файла и чтобы и проверяю валидность

Вот только бизнес логика заставляет меня встроить еще десяток проверок на корректность первичных данных, иначе такая фигня получается, хотя с точки зрения TDD тесты проходят
   Конструктор1С
 
139 - 03.10.20 - 16:37
(135) я говорю про модульное тестирование, и TDD как частность этого тестирования. Сходи на форумы не 1сные, спроси нужно им или нет модульное тестирование

(136) вот внёс ты точечные изменения в модуль на 100k строк кода, BDD показывает, что что-то сломалось. Дальше что?
   Aleksey
 
140 - 03.10.20 - 16:38
(139) У тебя какое то странное представление о BDDи TDD
   Конструктор1С
 
141 - 03.10.20 - 16:39
(138) "Вот только бизнес логика заставляет меня встроить еще десяток проверок на корректность первичных данных, иначе такая фигня получается, хотя с точки зрения TDD тесты проходят"

кажется я тебе уже писал, что ты тоже в TDD ни в зуб ногой
   PR
 
142 - 03.10.20 - 16:39
(139) LOL
Дальше ты смотришь свой говонокод, что ты там такого наменял, епта
   Конструктор1С
 
143 - 03.10.20 - 16:40
(140) судя по твоим каментам, у тебя представление о TDD куда страннее
   Lama12
 
144 - 03.10.20 - 16:41
(0) Очередная серебренная пуля. Нихрена это не поможет. Только больше времени будете тратить.
   Конструктор1С
 
145 - 03.10.20 - 16:42
(142) а если изменений на 10k строк и их вносили одновременно семь человек? Все 10k строк будешь перепроверять?
   Конструктор1С
 
146 - 03.10.20 - 16:42
Или озадачишь всех семерых, чтобы каждый из них потратил несколько часов на перепроверку своего кода?
   Aleksey
 
147 - 03.10.20 - 16:43
С точки зрения теста они абсолютно одинаковы что тесты для BDD что для TDD. Разница в подходе т.е. ты ничего не знаешь что будет происходить внутри этого модуля при TDD и можешь максимум прописать тесты для заранее подготовленых параметров. А с точки зрения BDD я уже знаю логику работы и пишу тесты не только для выходных параметров но и проверка ситуаций которые могут возникнут внутри модуля.
Т.е. я легко могу использовать тесты из TDD в BDD программирования, а вот более широкие тесты из BDD в TDD я не могу использовать, потому что незнаю что у меня будет происходить внутри
   Конструктор1С
 
148 - 03.10.20 - 16:46
(147) "С точки зрения теста они абсолютно одинаковы что тесты для BDD что для TDD"

По-сути это разные методики с разными подходами к тестированию. Более того, их вообще используют разные люди. TDD это для разработчиков, BDD больше для аналитиков, пользователей
   PR
 
149 - 03.10.20 - 16:47
(145) А если у тебя завтра на лбу рог вырастет?
К чему эти тупые примеры?
Приведи нормальный конкретный пример
   Конструктор1С
 
150 - 03.10.20 - 16:48
(149) оп-па-на! Т.е. групповая разработка и динамичные изменения это тупые примеры? Ну я прям не знаю, что тут сказать...
   PR
 
151 - 03.10.20 - 16:52
(150) Да ты дебил что ли?
Тупой пример — это когда берем сферического коня в вакууме, которого в течение недели семь рыл одновременно переписывают в говно
Хороший пример — это когда ты говоришь про конкретную задачу (например, доработка загрузки документов из банка) и когда нет дебильных допущений типа семи говнокодеров, одновременно переписывающих функционал в усмерть
   Конструктор1С
 
152 - 03.10.20 - 16:54
(151) шта? Ты хочешь чтобы я привёл тебе пример модульного тестирования, которого впринципе нет в 1с и которое не позволяет выполнять концепция платформы?
   PR
 
153 - 03.10.20 - 16:54
(150) Не, если там, где ты работаешь, вы всегда так и делаете, берете какой-то код (неважно какой, лишь бы побольше) и всемером его начинаете ушатывать до неузнаваемого состояния, ну тогда да, мои извинения, против такого пиздеца сложно что-то сказать, тут лучше такую команду сразу сжечь к чертям
   PR
 
154 - 03.10.20 - 16:57
(152) Ты либо совсем кретин либо троллишь
Я хочу, чтобы ты мне привел пример ЗАДАЧИ, в которой нужно доработать код, который вчера работал, а после доработки может поломаться и где чрезвычайно полезны будут TDD, потому что ничего другого здесь не спасет отца русской демократии
   Конструктор1С
 
155 - 03.10.20 - 17:01
(153) а на крупных проектах только так и работают. У нас человек 20 "ушатывают" одну конфу, зачастую двое-трое долбят один и тот же общий модуль

(154) ЛЮБАЯ задача разработки прекрасно ложится под TDD. Хватит нести истеричную ахинею. И погугли уже наконец-то что такое TDD. Вот тебе даже видос, как оно происходит
https://www.youtube.com/watch?v=y8TcPr73Bwo
   PR
 
156 - 03.10.20 - 17:02
(155) Ладно, я понял, пример ты привести неспособен
   Конструктор1С
 
157 - 03.10.20 - 17:03
(156) в (58) привёл простейший пример, но ты его даже не понял
   PR
 
158 - 03.10.20 - 17:05
(157) А, ну наконец-то, гора родила мышь, блеать, не прошло и полдня
   PR
 
159 - 03.10.20 - 17:10
+(158) Отлично, смотрим пример из (58)
Как я уже сказал, ценность небольшая, потому что функция крайне простая, проверена единожды в процессе ее создания
Вероятность того, что она поломается из-за изменений какого-то другого кода — минимальна
Поэтому в дополнительных тестах я смысла не вижу
   PR
 
160 - 03.10.20 - 17:11
+(159) Это плохой пример, берем другой или что?
 
 Рекламное место пустует
   spock
 
161 - 03.10.20 - 17:12
Почти всегда BDD это сценарные/поведенческие тесты. Зависят от данных и выполняются значительное время.
TDD же легкие тесты, которые дают моментальную обратную связь:не сломал ли свой код или соседский в каком-то левом модуле.
Спор ниочем. Нужны как одни, так и другие подходы.
Нужно быть дебилом (раз пошла такая терминология) применять BDD на этапе разработки и ждать n-часов/минут, при каждом коммите.
   IPcorp
 
162 - 03.10.20 - 17:13
Пишите исчо, интересное чтиво однако 😏 А так соглашусь, 1с, даже 8, это как убогенький динозаврик, отстает так лет на 15 от современных техов. НО! Альтернатив, как таковых, толковых не наблюдается, так что юзаем то что есть и молча киваем. Ну нет там возможности tdd нормально заюзать, но что же поделаешь. Это не опенсорсный продукт, так что такой возможности, быстрее всего, и не появится. Да, язык никакой, что можно было бы одной строкой сделать, приходится терять время и кнопки давить. Да и редактор так себе, с тем же отставанием. Модульность никакая, на простые, казалось бы, решения, приходится "велосипедить". Да и тот же конфигуратор хотелось бы в темных тонах, а не цвета "неожиданности", что бы глаза меньше уставала, но для этого просто еще лет 15 нужно подождать, и все будет... в общем, как и сказал, альтернатив толковых пока нет, так что пользуемся, и дружно киваем 😎
   PR
 
163 - 03.10.20 - 17:15
(161) Что такое этап разработки? Когда ты делаешь пулл реквест — это все еще разработка?
И что дебильного перед помещением своих доработок в мастер проверить их на работоспособность?
   Конструктор1С
 
164 - 03.10.20 - 17:17
(159) проверка этой функции уже сама по себе ценность. Функция покрыта тестами. И это не какая-то там проверка при беглой отладке, когда ты проверил на первых попавшихся данных, а именно проверка на разных входных данных. Чтобы без модульных тестов проверить эту функцию на нескольких входных данных, тебе придётся отдельно повозиться. К тому же завтра в эту функцию могут внести изменения, на этот случай будут тесты
   Конструктор1С
 
165 - 03.10.20 - 17:19
(61) "Нужны как одни, так и другие подходы"

Повторите, пжалста, погромче. Для сидящих на последнем ряду
   PR
 
166 - 03.10.20 - 17:22
(164) Моя проверка на первых попавшихся данных будет быстрее, а результат тот же
А если кто-то будет в нее вносить изменения, то пусть он и думает головой, что меняет и проверяет снова, что ничего не поломал
А тебя послушать, так твои тесты прямо панацея, можно уже и не думать головой, что пишешь и не проверять самому, тесты же есть
   PR
 
167 - 03.10.20 - 17:24
(165) Ты бы лучше пример нормальный привел
   Aleksey
 
168 - 03.10.20 - 17:25
(164) Проверка на входящих данных не гарантирует корректность
   Timon1405
 
169 - 03.10.20 - 17:25
(145) про диагностику автобуса: если изменения вносили 7 человек, этож 7 разных комитов(в dev-brachах), на каждый из которых можно натравить BDD. который из них упал тот и валенок. или проблема в большом времени BDD?
   spock
 
170 - 03.10.20 - 17:25
(163) Перед помещением проверить? Можно, но нужно:
- иметь актуальную тестовую базу. Хорошо, если она есть и небольшая. А если большая или данные тебе не положено видеть?
- сборочный конвейер. Прикольно если у всех есть jenkins и docker
   Asmody
 
171 - 03.10.20 - 17:27
У ТС каша в голове. Он почему-то (как, впрочем, и другие адепты) ставит знак равенства между "тестирование" и TDD.
Но это вещи вообще из разных координат.
   Конструктор1С
 
172 - 03.10.20 - 17:29
(166) не будет быстрее. Возвращаясь к тому же примеру

Во время отладки проверишь ты на входящей дате 03.10.2020, функция вроде бы работает. Но потом выяснится, что праздничные дни она неправильно переносит. СледующийРабочийДень(31.12.2020) у тебя возвращает 01.01.2021 вместо 11.01.2021. Но ты узнаешь об этом только от юзеров, вышедших на работу после праздников. А так ты заранее можешь проверить на некоторых пограничных или особых входящих данных, не задрачиваясь на перезапуск отладки/перепроведения и иже с ним. А так твой код легко и просто проверяется на разных наборах данных

СледующийРабочийДень(03.10.2020) = 05.10.2020
СледующийРабочийДень(20.10.2020) = 21.10.2020
СледующийРабочийДень(31.12.2020) = 11.01.2021
   Asmody
 
173 - 03.10.20 - 17:29
Я, кстати, не видел пока ни одного адекватного способа тестирования СКД.
   PR
 
174 - 03.10.20 - 17:29
(168) Дяденька не понимает, что даже в его примере может быть 2022 год или наоборот 2018 год
Или в регистре не будет каких-нибудь дат, а в тестах этот случай не будет учтен и алгоритм вернет не то, что нужно
Или еще 100500+ возможных упс

Но виновата, да, 1С, что не сделала поддержку нормальных TDD-тестов, ага
   Конструктор1С
 
175 - 03.10.20 - 17:30
(171) я не ставлю между TDD и тестированием знак равенства. С чего ты взял?
   Конструктор1С
 
176 - 03.10.20 - 17:31
(174) так твоя беглая проверка на первых попавшихся данных учтёт намного меньше случаев. Точнее всего один случай
   PR
 
177 - 03.10.20 - 17:33
(170) >>иметь актуальную тестовую базу. Хорошо, если она есть и небольшая. А если большая или данные тебе не положено видеть?
Она есть
Она небольшая и недостающие тестовые данные в нее набиваются Ванессой
По фигу на размер
Права есть

>>сборочный конвейер. Прикольно если у всех есть jenkins и docker
У нас есть, обращайся
   PR
 
178 - 03.10.20 - 17:39
(171) +1
   PR
 
179 - 03.10.20 - 17:40
(172) Ага, ты типа умный, а кругом имбецилы, хи хи
Не сцы, я на 31.12.2020 проверю, не дурнее тебя чай
   Конструктор1С
 
180 - 03.10.20 - 17:46
(179) не проверишь, ибо тебе для этого нужно будет создать и заполнить отдельный документ с датой 31.12.2020, и ещё миллион лишних движений. Тут не вопрос ума, тут вопрос трудозатрат на такую проверку
   Web00001
 
181 - 03.10.20 - 17:55
С удовольствием читаю ветку. Очень интересно. Но не могу понять простую вещь. Наверное потому, что не юзаю ни первое, ни второе. Никак не могу понять почему PR рассказывает, что его тесты будут учитывать большинство ошибочных ситуаций которые могут произойти, а TDD тесты с окажутся тупыми? Потому, что TDD тестов надо больше или потому, что BDD методика обладает более широкими возможностями? Ведь как я понял в BDD тоже юзер не будет писать "В этом поле я хочу видеть след. рабочий день. Да да да и после 01.01 должно идти 07.01 а не 02.01 как в прошлый раз". Он просто напишет "В этом поле я хочу видеть след. рабочий день". Все. То есть маху дадут оба подхода. Или где я ошибся PR?(можешь дразнить меня дебилом, я не обижаюсь)
   PR
 
182 - 03.10.20 - 18:09
(176) С чего бы один, могу и пяток проверить, даже тех же самых, кстати
   PR
 
183 - 03.10.20 - 18:10
(180) Ага, да, ты через TDD проверишь, а я через отладчик нет, да, все так и есть
   ДенисЧ
 
184 - 03.10.20 - 18:11
(181) Тут просто.
БДД показывает "функционал не работает."
ТДД показывает "не проходит вот этот конкретный тест"

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

И да. Даже если все т из тдд показывают зелёный, это не значит, что пройдут все бт
   ДенисЧ
 
185 - 03.10.20 - 18:12
(183) В тдд у тебя будет 100500 тестов с разными данными. А тебе в отладчике придётся все эти 100500 значений руками каждый раз вводить.
   IPcorp
 
186 - 03.10.20 - 18:15
(181) Да тут странный холивар, и поэтому интересен :) Как по мне, тестирование, это довольно обширное, общее, понятие. А TDD просто подход к разработке, когда сначала пишутся тесты, какой результат у нас должен быть, а затем под них код, дающий этот результат. И, естественно, это по времени более затратно будет. Зато дальнейшая поддержка кода намного проще, даже другим разработчиком. И само собой, в более-менее серьезном проекте, ни одни тесты не покроют его на все 100%. Где-то чего-то потом вылезло, ну дописали мы на это дело проверку, и все дела, пусть работает дальше. Зато запороть код вмешательством уже намного сложнее. Где-то чего-то поправил, прогнал тесты, проходят, значит все ок. Но читать топик интересно. Лишь бы одеяло не порвали :)
   PR
 
187 - 03.10.20 - 18:18
(181) Я не утверждаю, что BDD-тесты будут учитывать большинство ошибочных ситуаций
Я утверждаю, что они будут покрывать определенные пользователем критические операции
И объем этих тестов можно наращивать по мере необходимости и по мере выявления ошибок
А TDD-тесты к пользовательским сценариям не имеют никакого отношения
И поэтому непонятно, какие TDD-тесты очень важно написать и поддерживать, а на какие в принципе можно подзабить или вообще положить с прибором

В BDD, кстати, пользователь на Геркине напишет именно как раз, что он ввел в такое-то поле 31.12.2020, после чего в другом поле стало 11.01.2021
Геркин не настолько умный, чтобы оперировать понятиями "Следующий рабочий день"

Дразнить я тебя не буду, с чего бы
   PR
 
188 - 03.10.20 - 18:20
(184) В BDD не просто "Не работает", там известен шаг, на котором все накрылось медным тазом
А у нас еще и скрин экрана в момент, когда все квакнуло
   Конструктор1С
 
189 - 03.10.20 - 18:22
(183) тогда у тебя не получится быстрее. Вот мы и начинаем открывать плюсы модульных тестов)
   ДенисЧ
 
190 - 03.10.20 - 18:22
(188) Каждый шаг состоит из миллиметров.
Если же у вас бт покрывают миллиметры, то чем они отличаются от просто юнит-тестов?
Правильно - ничем.
   PR
 
191 - 03.10.20 - 18:22
(185) Да, это единственно интересный сценарий, я думал про него
Правда, Конструктор про него промолчал, поэтому я не стал за него искать аргументы в пользу TDD
Но тут есть нюанс
Для 100500 вариантов нужно 100500 верных ответов, ага
   ДенисЧ
 
192 - 03.10.20 - 18:24
(191) Эти верные ответы записаны в тестах в виде ассертов. А не картинок.
   Bigcalm
 
193 - 03.10.20 - 18:24
Это все круто конечно, ТДД, БДД, тестирование, скрамы хренамы, но вот смотрю я на обновления софтин в своем айфоне, и вижу, что "тут мы исправили...", а "тут мы в порядок привели", и все в таком духе. Причем одни и те же релизы обновлений могут выходить по нескольку раз за короткий промежуток времени.
Если речь идет о серьезной разработке серьезных систем для серьезных контор, то может быть такие технологии и важны, но в целом в 1с - кому это уперлось?
Сеебстоимость считает? Баланс сводит? ЗП считает там как-то ... И привет)
   PR
 
194 - 03.10.20 - 18:24
(186) Я не утверждаю, что таких нет, но пока не услышал примеров, когда TDD было бы интересно и оправдано
   Конструктор1С
 
195 - 03.10.20 - 18:26
(191) я тебе весь топик пытаюсь объяснить, что TDD это вжух - и прогнал свеженаписанную функцию через свеженаписанный тестик с множеством вариантов
   PR
 
196 - 03.10.20 - 18:27
(189) Получится
Потому что мне не придется вообще в принципе предусматривать вариант работы кода в режиме тестов
И потому что я тупо в отладчике за 15 секунд вычислю, что мне вернет функция для такого-то параметра
И забуду про эту функцию, возможно, на всю оставшуюся жизнь
   PR
 
197 - 03.10.20 - 18:28
(189) Кстати, а кто будет писать TDD-тесты для TDD-тестов?
   PR
 
198 - 03.10.20 - 18:29
(190) Не покрывают
Но и работают не по принципу булево, типа все прошло или где-то упало
В большинстве случаев информации более чем достаточно, чтобы быстро понять, почему тест упал
   PR
 
199 - 03.10.20 - 18:31
(192) И кто эти ответы вычисляет?
И не пользуется ли он для их вычисления этой же функцией, для проверки которой он их вычясляет?
   PR
 
200 - 03.10.20 - 18:32
(195) И где же ты берешь эти вжух-проверки? Кто их наполняет?
  1  2  3  4  5   

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