Вход | Регистрация
    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С
 
201 - 03.10.20 - 18:41
(196) "И потому что я тупо в отладчике за 15 секунд вычислю, что мне вернет функция для такого-то параметра"

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

(197) никто. Зачем их писать?

(199) это уже на совести разработчика. Мы тут не рассмартивает вариант раздолбайства и написания тестов ради шоб было. TDD предполагает, что разработчик заинтересован в правильности работы своего же кода

(200) разработчик сам пишет проверки. Это же TDD - разработка через тестирование. Т.к. гранулярность у тестов большая, то большинство проверок не сложные
   IPcorp
 
202 - 03.10.20 - 18:42
(199) А зачем вычислять результат теста функцией, которую потом же им и проверять будем ) Я вот думал результат вообще в таких случаях "не вычисляется". Входящие параметры: 2, 2. На выходе что должно быть: 4. Фсё. Передали параметры, получили ответ, сравнили. И по поводу "интересно и оправдано", тут либо сам решаешь, либо требование такое. Я вот ни разу никаких тестов не писАл. По времени экономия. Но если настроен упростить жизнь тому, кто после тебя будет код поддерживать, да и самому, если проект объемный, можно было бы. Но пока не писАл :) И вообще, многие тесты часто и пасАть то странно. К примеру в том же javascript, не будет же на каждый чих писать что 0.1 + 0.2 равен строго 0.3, хотя и не мешало бы ) Тут еще и от компетенции разработчика все зависит. В общем не знаю о чем тут даже спорить )
   PR
 
203 - 03.10.20 - 18:45
(201) А примера с не единственным параметром я не увидел, так что не понимаю, зачем мы обсуждаем сферического коня в вакууме
   PR
 
204 - 03.10.20 - 18:46
(201) Что значит зачем писать правильные ответы?
А с чем ты собираешься сравнивать результат функции?
   PR
 
205 - 03.10.20 - 18:48
(201) А, прикольно, че
Написал функцию получения следующего рабочего дня и тут же быстренько наипенил 100500 вариантов входных параметров и верных ответов
   PR
 
206 - 03.10.20 - 18:51
(202) Ну то есть быстренько нахреначить 100500 вариантов с параметрами и верными ответами — это минутное элементарнейшее дело?
   Конструктор1С
 
207 - 03.10.20 - 18:56
(203) ну пускай будет вот так
ВозрастФизлицаВГодахНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=869d0050568b35ac11e4ce0a151c2318, 12.02.2020) = 42
ВозрастФизлицаВГодахНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=869d0050568b35ac11e4ce0a151c2318, 13.02.2020) = 43
ВозрастФизлицаВГодахНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=92f10050568b35ac11e4f4cff814af7d, 16.08.2020) = 29
ВозрастФизлицаВГодахНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=b3380011955cba6b11df72ece91d1737, 16.08.2020) = 29

Или вот так

ФамилияИмяОтчествоФизлицаНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=869d0050568b35ac11e4ce0a151c2318, 12.02.2020) = "Иванов Иван Иванович"
ФамилияИмяОтчествоФизлицаНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=92f10050568b35ac11e4f4cff814af7d, 12.02.2020) = "Петров Пётр Петрович"
ФамилияИмяОтчествоФизлицаНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=b3380011955cba6b11df72ece91d1737, 12.02.2020) = "Сидорова Софья Павловна"
ФамилияИмяОтчествоФизлицаНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=b3380011955cba6b11df72ece91d1737, 15.02.2020) = "Петрова Софья Павловна"
   IPcorp
 
208 - 03.10.20 - 18:57
(204) Я говорил что на некоторые моменты просто вообще тесты писать странно, это раз. И про "быстро нахреначить" не совсем понял. Уже же сказал, при тесте есть входные параметры, есть результат, который должен получиться. Если тебе нужно проверить функцию получения следующего рабочего дня, ты для тестов его не вычисляешь. Берешь следующий рабочий день по факту, и сравниваешь с тем, что возвращает тебе функция. Было бы интересно, если бы написал свою методику тестирования, а то "не могу понять", как говориться ) Ты результаты для тестов вычисляешь теми же функциями которые и проверяешь что ли? Хм...
   PR
 
209 - 03.10.20 - 19:03
(207) О, прикольно, пример, в котором само собой разумеющееся, что функция без проблем определит физлицо по адресу
Действительно, все же так умеют, ничего специально для этого писать не нужно
И само собой, что проверка этой же функции только в отладчике в виде "ВозрастФизлицаВГодахНаДату(Справочники.ФизическиеЛица.НайтиПоКоду("001"), '20200212')" займет годы, если не десятилетия
   PR
 
210 - 03.10.20 - 19:08
(208) Про "быстро нахреначить" я говорю про то, что тут появился аргумент про 100500 проверок
Я и говорю, кто их и как готовит-то, эти 100500 вариантов?

Никакой своей методики у меня нет
Конечно же берется одно или несколько действий и вручную на Геркине определяется, что должно быть после этих действий
Только никаких 100500 проверок нет, есть одна, две, может три проверки, но не 100500 точно
   Конструктор1С
 
211 - 03.10.20 - 19:21
(209) после твоего отладочного подсовывания разных значений для потомков что-нибудь останется? А если входные значения станут ещё сложнее, то ты их просто не подсунешь

(210) в большинстве случаев 1сники проверяют на одном-двух вариантах значений, и их совершенно не беспокоит, что покрытие далеко от стопроцентного. Если будут проверять не на единственном первом попавшемся значении, а на ста разных значениях, это уже добавляет коду надёжности. Да, стопроцентного покрытия может и не быть. Но оно будет больше, чем проверка на первых попавшихся под руку данных
   Конструктор1С
 
212 - 03.10.20 - 19:25
да и если код у тебя по-человечески организован, никаких 100500 проверок не нужно. Для той же функции ВозрастФизлицаВГодахНаДату() тебе достаточно проверить на паре обычных людей на разных датах (до д.р., после д.р., в сам д.р.), и на людях с "интересными" датами рождения (1 января, 31 декабря, 29 февраля). Этого должно быть достаточно. Вовсе не нужно пропускать через функцию всех работников предприятия
   IPcorp
 
213 - 03.10.20 - 19:26
(210) Не знаю что за аргумент в 100500 проверок, то чем их больше, тем лучше. В любом случае, на 100% результат рассчитывать не нужно, потому как всегда что-нить да может вылезти. И да, результаты нужно заведомо правильные, и не важно как они получены. Если в цикле получаешь 100500 результатов для проверки, то тогда уж сядь и предварительно просмотри, верны ли они, иначе никак. В общем не знаю о чем тут и говорить-то, когда всё очевидно.
   PR
 
214 - 03.10.20 - 19:29
(211) Не останется. А зачем?

Про еще сложнее опять сферический конь в вакууме
Типа я вот в TDD все мухой делаю и получаю мегаништяки, а ты в отладчике упашешься до седьмого пота
Давай пример, тогда и обсудим и трудоемкость написания TDD и сложность вычисления в отладчике и полезность TDD для потомков
   Конструктор1С
 
215 - 03.10.20 - 19:29
Но как я говорил, TDD неплохо дисциплинирует, заставляет думать над сигнатурой методов и упрощать её при при возможности. Скорее всего ты из функции ВозрастФизлицаВГодахНаДату() выделишь функцию более нижнего уровня ВозрастНаДату(ДатаРождения, ДатаПроверки), и напишешь тесты уже для этой функции. А для функции ВозрастФизлицаВГодахНаДату() напишешь более простую проверку

ВозрастФизлицаВГодахНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=869d0050568b35ac11e4ce0a151c2318, 12.02.2020) = Тип(Число) И > 0
ВозрастФизлицаВГодахНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=869d0050568b35ac11e4ce0a151c2318, 13.02.2020) = Тип(Число) И > 0
   Конструктор1С
 
216 - 03.10.20 - 19:30
(214) как это зачем? После тебя этот код будут дорабатывать другие, и перед ними встанет та же самая задача проверить код
   PR
 
217 - 03.10.20 - 19:31
(211) В большинстве случаев одинесники проверяют на принципиально разных вариантах, а не на 100500 однотипных вариантах
Так что 100500 вариантов (которые у нас как-то волшебным образом вдруг появились в готовом виде) никакой, нахрен, особой надежности не добавят
   PR
 
218 - 03.10.20 - 19:33
(212) Вот именно
Вполне достаточно проверить несколько вариантов один раз, возможно даже в отладчике
   PR
 
219 - 03.10.20 - 19:34
(213) Ну так прочти (185) тогда что ли, там в первый раз про 100500 проверок
   spock
 
220 - 03.10.20 - 19:35
(209) Ты пойми, что TDD/BDD нужны ни только для тестирования функциональности, а для автоматизации программерской рутины.
Отдел программистов, пишущих свой кусочек, и не лезут в другие модули, запросто в отладчике/руками и любым другим способом проверят свое.
Но, когда они лезут в чужие модули, то для каждой своей(!) правки сложно тестировать чужой код из других модулей.
Идеально, когда так:
- лабаешь код с юнит-тестами (до или после - дело привкуса)
- закоммитился в DEV-branch (код и тесты)
- jenkins/teamcity/etc прогнал все ют (или не все - дело внутренней политики)
- в моменте получил обратную связь, что ничего не сломалось
- ночью или когда еще запустили сценарные тесты
- пулл реквест в main (мы же с 01.10.20 забанили термин master из-за BLM)
- полный комплект тестов и вот релиз.

Все зависит от масштаба разработки.
И да, любые подходы тестирования не 100% гарантия. Просто нужно жить с коллегами по принципу - "не ошибается тот, кто ничего не делает" + "вылезла хрень, написали тест под этот кейс"
   PR
 
221 - 03.10.20 - 19:39
(215) Бред какой-то, тесты ради тестов, какая-то никому нахрен не нужная мешанина из кода, обреченная на уход в небытие через неделю после написания
Скорее всего после прихода нового прогера и его общения с руководителем будет так:
— А что это за обработка "Запуск TDD-тестов"
— А, это прогер до тебя писал TDD-тесты
— Так там несколько тестов выдают ошибки, надо же срочно поправить
— Забей, у него это говно никогда толком не работало, вечно что-нить менялось, а тесты он не обновлял
   ДенисЧ
 
222 - 03.10.20 - 19:40
(221) Вот ты себя и описал в лице этого начальника. Поэтому в бит и плюются )))
   Конструктор1С
 
223 - 03.10.20 - 19:41
(217) эти принципиально разные варианты всегда могут быть разбиты на отдельные составные части. Если для функции верхнего уровня РассчитатьЗарплату() возможны 100500 вариаций входных параметров, то для функции более низкого параметра РассчитатьПроцентОтБазы(База, Процент) вариаций будет намного меньше. Только вот 1сники никогда не проверяют РассчитатьЗарплату() на 100500 вариаций, да это и физически не возможно. Скорее всего эталонным будет вообще один документ, и в функции нижнего порядка попадёт совсем мало значений. Покрытие будет крайне низким. А с модульным тестами ты проверишь каждую функцию на десяти-двадцати входных вариантах. И проверка пройдёт очень быстро. Тебе не придётся перезапускать адронный коллайдер тыщу раз
   PR
 
224 - 03.10.20 - 19:42
(220) Когда правишь чужой код, то да, нужно сначала въехать
Но въехать нужно в любом случае, независимо от наличия TDD-тестов
Вообще в данном случае куда более ценным является читабельный самодокомментируемый код

А, и да, на BLM мне наплевать с чуть более высокой, чем самая высокая, колокольни, так что мастер
   PR
 
225 - 03.10.20 - 19:44
(220) По поводу не панацея согласен
Просто что точно не стоит делать — это писать тесты, которыми никто не будет пользоваться, потому что будет (221)
   PR
 
226 - 03.10.20 - 19:45
(222) Вечно ты ни к селу ни к городу, ляпнешь что-то, без поллитры не разберешься, что ты вообще имел в виду
   Конструктор1С
 
227 - 03.10.20 - 19:47
(221) ничего никуда не уходит. Всё аккуратненько лежит в определенном месте, и используется в будущем повторно. Твои проблемы надуманы. А модульное тестирование настолько стандарт в программировании, что современные IDE сами создают папки для тестов, сами подтягивают нужные для тестирования зависимости, и сами генерят заготовки тестов. Создал пустой проект, а у тебя уже есть служебная директория Test с заготовками
   PR
 
228 - 03.10.20 - 19:47
(223) У меня нет цели покрыть тестами код
У меня цель — покрыть тестами пользовательские сценарии работы
   Конструктор1С
 
229 - 03.10.20 - 19:48
(224) тесты кода позволяют лучше понимать код. В тестах ты сразу увидишь, что ожидается от кода
   Конструктор1С
 
230 - 03.10.20 - 19:49
(228) тогда тебе придётся постоянно иметь дело с трудноотлавливаемыми ошибками
 
 Рекламное место пустует
   PR
 
231 - 03.10.20 - 19:50
(229) LOL
В названии процедур, функций и переменных, в комментариях я вижу, что ожидается от кода
   spock
 
232 - 03.10.20 - 19:51
Важный момент - сценарные тесты часто протухают из-за изменения логики (первая буква в (B)DD). А юнит-тесты не протухают, потому что ты не закоммитишься, пока не приведешь свой код к проходу теста, либо актуализируешь тест.
   spock
 
233 - 03.10.20 - 19:54
И еще - берем проект с github'а и пытаемся разобраться с тем, как пользоваться API этого проекта.
Что мы делаем? Читаем доку и лезем смотреть тесты - тесты дополняют доку, а иногда спокойно заменяют.
Нет тестов? Епт, курим доку до посинения и надеемся, что в доке отражены все нюансы.
   PR
 
234 - 03.10.20 - 19:54
(230) Не такие они уж и трудноотлавливаемые
Они зачастую не более трудноотлавливаемые, чем в коде, покрытом TDD-тестами
И отлавливаю я важные ошибки, которые реально поломают работу пользователя
А с TDD-тестом хрен пойми, важный он или нет

Ладно, я смотрю, ты глух к аргументам и (171) тебе не зашло
   PR
 
235 - 03.10.20 - 19:57
(232) Все верно
Только TDD — это неуловимый Джо, хрен протухнет, зато никому нахрен не нужен
А BDD может меняться, да, зато приносит реальную пользу
   PR
 
236 - 03.10.20 - 19:58
(233) А что, обратный вариант невозможен что ли?
Что в доке все есть, а в тестах нихрена
   spock
 
237 - 03.10.20 - 20:04
(236) Ты зациклился на недостатках.
Подходы и инструменты помогают минимизировать программерские и пользовательские проблемы. Как конкретный индивид будет пользоваться инструментами зависит от его способностей.
Если тесты пишутся только, чтобы продавать услуги (у нас есть тесты, мы используем передовые подходы и прочий инфоцыганский треп), то ничего не поможет ловить ошибки.
А если команда заинтересована в качественном продукте, то они будут делать все, чтобы у них были юнит, сценарные и интеграционные тесты, и находились в актуальном актуальном состоянии.
   PR
 
238 - 03.10.20 - 20:09
(237) Просто я не думаю, что TDD полезны всегда и везде
Иногда да, в некоторых случаях да, но не более
   spock
 
239 - 03.10.20 - 20:16
(238) Если степень применимости скорректируешь, то с твоим высказыванием согласятся все мистяры )
   ДенисЧ
 
240 - 03.10.20 - 20:23
(226) Если ты без поллитры не можешь разобраться в нормальной русской речи, то у меня для тебя печальные новости - ты алкоголик в третьей стадии...
   israel
 
241 - 03.10.20 - 20:25
(226) он имел в виду, что если в БИТе такие бездарные руководители, которые за 200 постов не смогли понять зачем нужны TDD тесты, и как они работают, то понятно откуда неуважение к этой организации.
   PR
 
242 - 03.10.20 - 20:27
(239) Ну, например, функция со сложным матрасчетом, когда ты сам не уверен, что нигде не налажал

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

Или функция с алгоритмом, выведенным из предоставленного эксель-файла, когда ты вроде все сделал правильно, но вдруг есть варианты, которые ты не учел

Или когда ты пишешь ПО для военных или для АЭС

В общем, есть вагон вариантов, когда TDD уместен и полезен
Но глупо в любом случае на каждый чих сразу бросаться писать многочисленные 100%-нопокрывающие код TDD-тесты
   PR
 
243 - 03.10.20 - 20:29
(241) Спасибо, кэп, суть слов я понял и без подсказки
Непонятно, с какого перепоя он (221) в (222) спроецировал на меня
   Конструктор1С
 
244 - 03.10.20 - 20:30
(234) ошибка может быть мелкой, но приводящей к серьёзным последствиям. Да и странно такое читать от программиста. Типа ай, вот тут 2х2=5, но это мелочь, ничего страшного
   Конструктор1С
 
245 - 03.10.20 - 20:34
(235) модульные тесты точно также запускаются после каждого изменения. Ты можешь запустить их после правок, ведущий прогер запустит их при приёме твоей работы, архитектор запустит перед сборкой продуктовой версии... Это ещё большой вопрос, какими тестами чаще пользуются
   spock
 
246 - 03.10.20 - 20:36
(242) красавчик, мы в тебя верили )

ремарка - ют незначительно увеличивают тайминги. Проблема в том, что народ путает ют со сценарными. В (0) приведена цитата, которая выражает дух юнит-тестирования - простые куски кода-тесты без сложной логики - вызвал свою новую функцию, передал туда определенные параметры, проверил с ожидаемым результатом. Тут же граничные параметры так же проверил. И еще выходы за границы, чтобы твоя функция выдавала  ошибку/фигню и это тоже успешный тест. В общем - это несколько строк кода, вызывающего твои новые функции.
Но, если тест написал заранее, то ты уже спроектировал интерфейс функции (API) и дальше программировать будет легче и быстрее из-за того, что не будешь метаться: а правильно ли я спроектировал функцию(и).
   israel
 
247 - 03.10.20 - 20:38
(243) Потому что ты всю ветку ведёшь себя как руководитель из (221), обесценивая пользу TDD, хотя сам просто не понимаешь как это работает, а самое главное – не понимаешь главную пользу, при таком подходе намного труднее писать говнокод и легче совершенствовать код.
   israel
 
248 - 03.10.20 - 20:39
(242) Именно, TDD имеет смысл в серьёзных системах, работающих 24/7 например.
   israel
 
249 - 03.10.20 - 20:39
Там где минута простоя это миллионные убытки
   Злопчинский
 
250 - 03.10.20 - 20:41
вот сейчас у меня проектик будет. я сначала сценарий работы отталкиваясь от интерфейса буду планировать, а до функций - вот хз когда. все равно получается классический "сверху-вниз"
   israel
 
251 - 03.10.20 - 20:41
А 1с к таким не относится )))
   Злопчинский
 
252 - 03.10.20 - 20:43
(248) ага, где архитеторыв, тестировщдики и прочие хрени...
много тут 1Сников которые в каждой конторе где они работают/обслуживают по нескольку 1с-человек над одним проектом работают?
   spock
 
253 - 03.10.20 - 20:50
(250) проектирование продукта и реализация в коде - они на разных уровнях. TDD - это про программирование, как бы последняя буква D на это намекает. Дизайн/проектирование из другой истории.
Чё начинаешь? )
   israel
 
254 - 03.10.20 - 20:52
(252) Всё так, в 1с TDD нужно большим командам, писателям типовых, например
   israel
 
255 - 03.10.20 - 20:54
кстати сейчас подумал почему типовые такие вечно косячные – там нет TDD )))
   israel
 
256 - 03.10.20 - 20:55
как будто в других местах работают другие люди, такие же программисты делают более качественные продукты, просто у них другие техники, в частности наличие TDD
   Злопчинский
 
257 - 03.10.20 - 22:53
(255) ТДД - это инструмент.
там имхо нет системности нормальной в ПРОМЫШЛЕННОЙ разработке и выпуске продукта.
при отсутствии (условно) плана работ - инструмент ситуацию не спасет., поможет малость, это наверное да. доски будут отрезаны ровно. но дом построен при этом криво ;-)
   Aleksey
 
258 - 04.10.20 - 00:06
Так все таки если мы Тесты пишем на заранее подготовленных данных (поиск справочника по рефу), 

А. Как эти тесты будут работать на боевой базе, где нет тестовых данных
б. Как они помогут в поисках ошибок если они проверяют только тестовые данные, а не реальные
   Aleksey
 
259 - 04.10.20 - 00:07
Это какой то нарциссизм, писать код ради кода и даже тесты для него придумывать, чтобы код был идеальный. И пофиг что на реальных данных программа ведет себя неправильно, главное что код красивый
   Aleksey
 
260 - 04.10.20 - 00:17
Почему, согласно статистики, TDD снижает процент ошибки всего лишь на 40%, а не на 100%. Ведь мы сразу пишем тесты покрывающие 100% плюс у нас красивый, идеальный код, но даже это не спасает и от половины ошибок. В чем подвох?
К тому же почему у крупных компаниях есть статистика как полоджительного использования, так и отрицательного. Ведь TDD она же позволяет быстрее писать программы и главное без ошибок и красивый код, но Ишь ты, поди ж ты
 
 Рекламное место пустует
   Конструктор1С
 
261 - 04.10.20 - 05:20
(258) обычно есть какая-то копия данных из рабочей базы. Тест должен покрывать не все реальные данные, а возможные вариации этих данных. Незачем проверять функцию получения возраста на всех физлицах когда-либо работавших на предприятии, достаточно прогнать функцию на нескольких вариантах, охватывающих большинство возможных случаев

(260) невозможно достичь идеального результата. Да и профит от TDD не только в уменьшении количества ошибок, там есть масса вкусных "побочных" эффектов, упрощающих жизнь с написанным кодом
   Конструктор1С
 
262 - 04.10.20 - 05:54
+TDD это не столько про тестирование, сколько про разработку
   МимохожийОднако
 
263 - 04.10.20 - 07:48
ОФФ: Постарался прочитать всё ) 
Вспомнился монолог героя миниатюр Аркадия Райкина: "Пуговица пришита крепко? Претензий нет?" это TDD
"Но не на том месте..." это BDD
Вечная песня "профессиональных" программистов, что 1С-ники "недо.." 
...
ИМХО. Применение каждого инструмента необходимо в конкретном контексте, проекте и т.д. Кто-то кусачками обходится при монтаже, а у кого-то целый баул различных приблуд. Зависит от объемов и необходимости. Если какой-то инструментарий не применяют, то либо дорого, либо неэффективно.
А теоретизировать можно до бесконечности. Если программиста не остановить, он будет дорабатывать до бесконечности. Не я это придумал )
   Конструктор1С
 
264 - 04.10.20 - 08:29
(263) не совсем так. При модульном тестировании, и разработке через TDD в частности, код получается более покрытым тестами. Без модульного тестирования чаще как в том анекдоте про программиста на стрельбищах,промазавшего мимо мишени: "у меня все пули вышли, проблема на вашей стороне"
   Mort
 
265 - 04.10.20 - 09:20
Имхо TDD вообще в первую очередь не про качество кода и защиту от ошибок, хотя "Test" в названии вводит в заблуждение. TDD позволяет программисту четко идти к результату и делать только то что требуется, а не распыляться в разные художества. Косвенно это влияет и на качество кода, но в первую очередь профит это производительность, о чем было сказано в (0). Хорошие прораммисты могут и без этого, но где взять на крупный проект исключительно хороших?
   PR
 
266 - 04.10.20 - 09:44
(262) Аллилуйя, наконец-то ты отделил мух от котлет, я уж думал, этого никогда не случится
   PR
 
267 - 04.10.20 - 09:47
(264) А ты ведь вообще не понимаешь разницы между ошибками в коде и логическими ошибками, я смотрю? :))
Пример с пуговицей тебе явно не зашел
   PR
 
268 - 04.10.20 - 09:48
(265) Да, и здесь есть одна огромная засада, я ее описал в (33)
   Стаканов
 
269 - 04.10.20 - 10:00
А вообще, это прекрасно, когда дилетанты обсуждают технологию, которой сами никогда не пользовались. Столько интересного узнать можно...
   Конструктор1С
 
270 - 04.10.20 - 10:01
(266) вообще-то я об этом написал ещё в (0)

(267) ты так и не понял суть модульного тестирования....
   МимохожийОднако
 
271 - 04.10.20 - 10:03
(270) Я правильно понял, что тебе не нравится отсутствие в разработках 1С модульного тестирования?
   МимохожийОднако
 
272 - 04.10.20 - 10:05
Конвейер вещь хорошая, но на очень крупных предприятиях. В малых проектах ("ларьках" ) ) вещь не нужная.
   Конструктор1С
 
273 - 04.10.20 - 10:07
(268) ты прямо настойчиво не хочешь понимать, что такое TDD...
   PR
 
274 - 04.10.20 - 10:07
(270) Я тебе про то, что ты хоть обпокрывайся все TDD-тестами, это примерно как со всех сторон прикрыть голову самыми лучшими материалами, которые защитят тебя от пули в голову
А потом тебе выстрелят куда угодно, кроме головы, и ты будешь сидеть и удивляться, ну как же так, я же все нахрен на 200% покрыл тестами, ну как же они все-таки смогли меня достать?
   PR
 
275 - 04.10.20 - 10:08
(273) Я понимаю, что такое TDD
Я говорю, что, как правило, нахрен оно не вперлось
   Стаканов
 
276 - 04.10.20 - 10:10
(275) Если бы ты понимал, что такое TDD, ты бы в этой теме не спорил :))
   МимохожийОднако
 
277 - 04.10.20 - 10:10
   МимохожийОднако
 
278 - 04.10.20 - 10:12
+(277) Мне понравилось фрагмент дискуссии из ссылки:"TDD - это всего лишь идеология использования тестов в качестве ТЗ. Формулируете требования, воплощаете их в тестах и только потом реализуете код, удовлетворяющий этим требованиям. Именно в таком порядке. Тесты могут быть говно, код может быть отстой, зато можно смело заявлять, что вы ведете разработку по TDD и это будет чистая правда."
   МимохожийОднако
 
279 - 04.10.20 - 10:15
https://tproger.ru/translations/test-driven-development-is-dumb/
Надеюсь не надоел со ссылками.) Но хотелось понять ради чего холивар
   Конструктор1С
 
280 - 04.10.20 - 10:29
(274) совершенно оторванная от реальности аналогия. С модульным тестом функция проверится на 30 вариантах входящих значений, на 28-м выловит багофичу. Без МТ функция проверится на 2-х первых попавшихся значениях, а то коварное 28-е значение выявится только в процессе эксплуатации. Что автоматом удорожит ошибку
   PR
 
281 - 04.10.20 - 10:40
(280) Ну, если тебе даже эта аналогия не зашла, умываю руки, ты непрошибаем, оставайся при своем мнении
   Конструктор1С
 
282 - 04.10.20 - 11:04
(281) ладно. Живи в своих заблуждениях
   Злопчинский
 
283 - 04.10.20 - 12:38
(197) я этот вопрос както тоже задавал. внятного ответа не получил. смысл такой что сами тесты простые и их не надо тестировать. ну так я код пишу так, что его не надо тестировать...
   Злопчинский
 
284 - 04.10.20 - 12:43
опять же - если тдд или бдд - это некая технология - то она должна поддаваться автоматизации. как любая технологическая задача. если нужно участие интеллекта в написании теста - это сугубая эмпирика. то есть зависит от человека. посему ели разработчик квалифицированный - он и без тестов напишет код, отрабатывющий в подавляющем количестве применений этого кода корректно. тесты пишем когда программер "тупой", тестировщик такой же тупой. понятно что две головы могут быть лучше чем одна - но это в том случае когда головы - умные. сумма двух тупых будет еще хуже чем у одного туупого просто в силу экономической неэффективности. имхо
   novichok79
 
285 - 04.10.20 - 12:50
В чем проблема то? Вы тратите больше времени на написание постов на мисте, чем на написание обработки, в модуле обработки ваш код - в форме тесты. Чем не JUnit?
   Конструктор1С
 
286 - 04.10.20 - 13:02
(284) на тру-языках всё автоматизировано. Например вот
https://ru.wikipedia.org/wiki/JUnit

в 1с пока ещё конь не валялся. Палки в колёса вставляет платформенная концепция, которая не позволяет запускать модульные тесты
   Конструктор1С
 
287 - 04.10.20 - 13:09
(285) примерно так и приходится делать - выдрал код во внешнюю обработку и тестишь. Проблема в том, что такой подход не универсальный, быстро создаётся свалка из внешних обработок, среди которых хрен разберёшь какая и зачем. А в тру-программировании модульные тесты аккуратненько хранятся в иерархической структуре, для запуска не нужно открывать каждый файлик теста вручную. Простыми кликами можно запустить один тест для одного класса/метода, или группу тестов, или ветку тестов, или все тесты сразу... Самое главное, где основной код лежит, там он и тестится. Не нужно его куда-либо выдёргивать и как-либо переделывать для тестов, в отличии от обработок 1с
   Злопчинский
 
288 - 04.10.20 - 16:37
- Пап, а кем ты работаешь?
- Проджект менеджером на аутсорсинговых проектах.
- А как это?
- Ну, представь, мне звонит заказчик и говорит, что у его клиента из живота торчит копье и надо срочно что-то делать. Я иду к людям и спрашиваю, что можно сделать. Потом звоню заказчику и говорю, что надо достать копье, но это будет стоить 1000$. Он говорит, что дорого. Я опять иду к людям и спрашиваю, что можно сделать дешевле. В итоге мы за 500$ загибаем копье и красим его в телесный цвет.
   Злопчинский
 
289 - 04.10.20 - 16:39
(286) нахрен труязыки :-)
Концепция 1С себя оправдала в той области где мы живем.
   Стаканов
 
290 - 04.10.20 - 16:40
(283) Смысл тестов в том, что они выполняются автоматически при каждом коммите кода. А так как в парадигме TDD коммиты будут очень маленькие, проблемы с кодом (и с тестами, если некоторые из них некачественные) будут выявлены максимально быстро.
   Злопчинский
 
291 - 04.10.20 - 16:41
(286) кто рожает тесты? спецюзвери? если да - чем это отличается от рожания кода спецюзверем/погромистом.
имхо при этом рожающий тесты д.б. еще более глубоко погружен в предметку чем кодер...
   Стаканов
 
292 - 04.10.20 - 16:41
(289) Ещё бы над модульностью поработали и средства разработки улучшили, так вообще не на что жаловаться :)
   Стаканов
 
293 - 04.10.20 - 16:43
(291) В BDD таки да, спецаналитики и спецпродактовнеры :)
   Злопчинский
 
294 - 04.10.20 - 16:47
(290) если коммиты маленькие - то нахрена тесты? при маленьком коммите я при написании кода уже его протестировал в башке. на это у меня ушло 30 мин. мне заплатят за 30 мин - в нашей сфере 1сников. никто мне нахрен не заплатит за просту печформу 5 тыс когда я еще все это формализую в виде тестов не в голове, а формальных тестов. при этом эта печформа будет неизменной года три как минимум... с ценами 1500 супротив 5000 я буду неконкуретноспособен на рынке "моей"/нашей автоматизации. в 90% (имхо) проектов 1С ТДД/БДД просто не живет. На каких/нить камазах/гахпромах где хайлоад и цена ошибки в печформе - миллион рублей - ну да, может быть...
   Злопчинский
 
295 - 04.10.20 - 16:47
(292) да вроде ЕДТ как норм. только батарейки тяжелые ;-)
   Стаканов
 
296 - 04.10.20 - 16:49
(294) А если над проектом не ты один работаешь, а человек 10? Ну понятно, конечно, что если ты фикси в одно лицо на каком-нибудь заводике, тесты тебе нахрен не впёрлись.
   Злопчинский
 
297 - 04.10.20 - 16:50
на каких-нить аджайлах где хренячатт "по месту" и рожают "коммиты" три раза в день - м.б. и имеет смысл.
если у меня есть время прогать вдумчиво, я обычно "сверху-вниз" прогаю ("рисую" остов крупными мазками и начинаю мелкими шажками детализировать - то и так вроде норм. Правда, со временем углубление в частности приводить к разрастанию кода/ветвлений/альтернатив - тут да, хорошо бы что-то автоматизированное тестить... Но так чтобы не я тиратил время на тесты... ;-)
   Злопчинский
 
298 - 04.10.20 - 16:51
(296) ну так про то и речь. а так как в шаей области один "фикси" может вполне тянуть контору на 30-50 работающих с 1С - то на проетах с 10 человеками в команде - это уже реальный "камаз"...
   Стаканов
 
299 - 04.10.20 - 16:52
(295) Ну, вон тут товарищи из БИТ говорят, что ERP ворочаться более-менее в ЕДТ начинает на топовом проце 8 ядер 32 ОЗУ. И при этом куча детских ошибок до сих пор не исправлены :(
   Стаканов
 
300 - 04.10.20 - 16:56
(294) Ты посмотри со стороны среднекрупного франча - там параллельно могут идти несколько проектов, может самих по себе и не очень больших, но сразу. И уровень кадров невысок относительно, тут без всяких парадигм из тру-языков качественную потогонку не устроишь :)
  1  2  3  4  5   

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