Вход | Регистрация
    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?
   Злопчинский
 
301 - 04.10.20 - 16:56
(299) и не будут исправлены в обозримое время. разрабы в полях не живут...
с другой стороны если ошибка не исправляется долго - значит некритично.
главное чтобы ошибку БЫЛО ВИДНО в работе.
   Злопчинский
 
302 - 04.10.20 - 16:57
(300) проблемы франч-индейцев меня-шерифа не волнуют.. ;-)
   Стаканов
 
303 - 04.10.20 - 16:59
(302) Во... то есть, объективно судить об этом вот всём ты априори не можешь :)
   Aleksey
 
304 - 04.10.20 - 17:01
(280) Я не понимаю тебя, с одной стороны ты тестишь на 3-4 фиксированных данных (иначе как узнать что функция возвращает правильный результат)
С другой стороны ты пишешь о каком то " 30 вариантах входящих значений"
Я правильно понимаю что это теже фиксированные значения. Т.е. ты проверяешь намертво ли пришиты пуговицы (ошибками в коде) и тебе пофиг на логические ошибки
   Aleksey
 
305 - 04.10.20 - 17:03
(300) Т.е вместо того чтобы нанять отдел тестирования мы будем заставлять прогеров, которые работают над своим кусочком и не видят картины в целом писать и проводить тесты? Т.е. пуговицы пришиты намертво
   Стаканов
 
306 - 04.10.20 - 17:07
(305) Тесты, которые не выполняются автоматически, нафик не нужны :) А тестировщики нужны, конечно, мы же в реальном, а не идеальном мире живём.
   Конструктор1С
 
307 - 04.10.20 - 17:08
(289) оправдала. Только системы всё сложнее и сложнее, а это уже требует других подходов к разработке
   ДенисЧ
 
308 - 04.10.20 - 17:08
(305) Никакой отдел тестирования (который, btw, проверяет функционал, а не отдельные функции) не поможет. Ибо тогда ПП вообще в прод не выйдет
   ДенисЧ
 
309 - 04.10.20 - 17:08
(304) Исчо один печОнкин...
Логические ошибки НЕ ПРОВЕРЯЮТСЯ юнит-тестированием...
   Стаканов
 
310 - 04.10.20 - 17:10
(309) Да, и юнит-тестирование это не TDD :)
   Злопчинский
 
311 - 04.10.20 - 17:11
(303) объективно я сужу только на уровне стоимости работ, которые, например, делает для меня франч.
   Злопчинский
 
312 - 04.10.20 - 17:12
(307) что в УТ11 в принципе настролько сложнее чем ТИС что требуетяс какая-то охернность? только СЛАУ?
   Стаканов
 
313 - 04.10.20 - 17:13
(311) Так это же не про мелкие локальные франчи речь, а так да, иногда берёшь их код на сопровождение, и не знаешь, толи охреневать, толи плакать :((
   Конструктор1С
 
314 - 04.10.20 - 17:23
(304) это были условные примеры. Нет никакого стандарта, что нужно по 5 проверок на функцию, например. Но так или иначе можно выйти на конечное число проверок, покрывающих наибольшее количество вариантов.
А одна из фишек TDD в том, что она мотивирует писать код более линейно, не делать громоздкие методы с десятью входными параметрами, которые придётся покрывать 100500 тестами, чтобы более-менее проверить. Это уже огромный профит. Помимо того, что код покрыт тестами, такой код легко изменять
   Стаканов
 
315 - 04.10.20 - 17:25
(314) А расскажи, кто будет платить за покрытие тестами? И почему они за это захотят платить?
   Конструктор1С
 
316 - 04.10.20 - 17:25
(305) а ты полагаешь, что тестеры смогут более эффективно протестировать тот код, который они не писали и логику которого скорее всего не понимают? Никто не понимает логику кода лучше, чем его автор
   Злопчинский
 
317 - 04.10.20 - 17:26
(314) целое не всегда равно сумме частей. сказывается кумулятивный эффект.
и если протетсить 5 простых функций с минимом параметров - то тестить более глобальную функцию, в которой используются эти 5 функций - сложнее или проще?
   Конструктор1С
 
318 - 04.10.20 - 17:30
(315) владелец системы. И тут всё просто, за НЕпокрытие тестами ему придётся платить ещё больше. Намного больше. Ошибка, выявленная на этапе написания кода, стоит копейки, на каждом следующем этапе становится всё дороже и дороже. На этапе промышленной эксплуатации цена ошибки может доходить до тысяч долларов и более. Но даже если ошибка никак не ударит по бизнесу, не вызовет простоев, не навредит репутации, всё равно её исправление обойдётся намного дороже, чем обошлось бы на этапе разработке
   Конструктор1С
 
319 - 04.10.20 - 17:33
(317) разумеется проще
   Стаканов
 
320 - 04.10.20 - 17:40
(318) Э... Да вы идеалист-теоретик, батенька.
   Конструктор1С
 
321 - 04.10.20 - 17:41
(320) почему?
   Стаканов
 
322 - 04.10.20 - 17:46
(321) Потому, что в (318) это теоретически правильно, а практически не так для 99,9% проектов на 1С в настоящее время.
   Злопчинский
 
323 - 04.10.20 - 17:50
(319) чем гарантируется что тестирование глобальной функции с входными параметрами  соответствует отработке тестов мелких функций? если каждая локальная функция протестирован на ну допустим на 5 вариантах входных параметров, то использование в глобальной функции этих 5 частных функций, в худшем случае порождает 5*5*5*5*5 вариаций параметров.
в лучшем случае - с сотню-две входных вариаций параметров глобальной функции... при наращивании стека вызовов - имеем эскалацию вариатов входных параметров...
   Конструктор1С
 
324 - 04.10.20 - 17:50
(322) это пока что. Но со временем до 1сной отрасли дойдёт, что гораздо дешевле обрезать ошибки "лишними" тестами на этапе разработки, чем мучительно отлавливать их на этапе эксплуатации. Во взрослом программировании понимание этого давно пришло, скоро и до 1с дойдёт. Всё то же отставание под эгидой "уникального пути"
   Конструктор1С
 
325 - 04.10.20 - 17:53
(323) так мелкие функции тестируются отдельно. Один-два параметра кормят одну нижестоящую функцию, ещё один-два вторую... Если на это сверху посмотреть с мозгом, озабоченным уменьшением вариаций (тебе же ещё тест под это писать!), то наверняка выявишь закономерности
   Стаканов
 
326 - 04.10.20 - 17:56
(324) Пока сам вендор не будет так работать, ничего не изменится глобально. И основной вопрос - а оно вендору надо? Что-то не видно пока у них в руководстве свежей крови, как это было в Microsoft.
   spock
 
327 - 04.10.20 - 17:58
(311) Необходимость и стоимость - могу дать свой живой пример.
Сейчас мне нужен парсер pdf-файлов. Структура pdf сама по себе дурная и делаю небольшими итерациями: научил парсер читать одни объекты, потом другие и тд
В процессе реализации уже были моменты, что ломал ранее работающий код парсера - где-то токен не обработал, где-то с пропуском whitespace'ов переборщил и спозиционировался не туда.

Вот если бы я делать это все без тестов (юнит в данном случае), то уже бы застрелился.
Но сейчас я могу спокойно поправить код, нажать на F7 и в моменте пронаблюдать качество своей работы. Я даже моргнуть не успею, как узнаю, что новая сборка кривая.
А код, например, такого теста примитивен и в этом его сила:
BOOST_AUTO_TEST_CASE(EmptyPage_details, * boost::unit_test::enabled()) {
    std::string filename("//test//resources//empty_page.pdf");


    std::unique_ptr<PDFReader> pdfReader = std::make_unique<PDFReader>(filename);
    std::shared_ptr<PDFDoc> pdfDocument = pdfReader->getPDFDocument();

    int major = 0, minor = 0;
    std::string pdfVersion = pdfDocument->getPDFVersion(&major, &minor);

    std::uintmax_t pdfFileSize = pdfDocument->getFileSize();
    int count = pdfDocument->getNumberOfPages();

    BOOST_TEST(pdfVersion == "1.6", "wrong pdf-version gotten");
    BOOST_TEST(major == 1);  // версия.мажор == 1

    BOOST_TEST(minor == 6);  // версия.минор == 6

    BOOST_TEST(pdfFileSize == 4880);  // размер файла 4880

    BOOST_TEST(count == 1);  // должна быть одна страница

}

   Стаканов
 
328 - 04.10.20 - 18:00
(327) А при чём тут 1С?
   spock
 
329 - 04.10.20 - 18:02
(328) я тут за тесты топлю )
   Конструктор1С
 
330 - 04.10.20 - 18:04
(326) работают. Платформа уже давно юнит-тестами покрывается. До конфигурациипиления пока что не дошло, сама платформа не позволяет. Но возможно в будущем... Недавно выкатили 1с:Исполнитель, а вот уже под него можно писать модульные (юнит) тесты, утилиты правда пока нет. Возможно 1С:Исполнитель это проба пера, и задумали новую платформу. Но это не точно

https://wonderland.v8.1c.ru/blog/1c-ispolnitel/
 
 Рекламное место пустует
   Злопчинский
 
331 - 04.10.20 - 18:06
(325) к сожалению в ЯП есть условные операторы, которые делают код нелинейным...
   Злопчинский
 
332 - 04.10.20 - 18:10
могу ошибаться, но пока не видел внятной демонстрации разработки хотя бы тривиального 1С-конфиги "количественный склад с партионкой по ФИФО" с использованием NLL/ чтобы тупо оценить - а печенька стоит выделки?
.
ps^ у меня обычно все "тесты" сводятся к тому, чтобы не допускать на вход алгоритма невалидные входные параметры.
   Злопчинский
 
333 - 04.10.20 - 18:11
а так да. я бы попрограммировал через ТДД и БДД.
самому начинать трудно без преальной прикладной задачи (даже инструмент освоить), а в падаваны меня никто не возьмет..
так и маюсь по старинке ;-) вроде ничего, норм... ;-) пока...
   Конструктор1С
 
334 - 04.10.20 - 18:13
(331) есть, но не только от них зависит линейность-нелинейность кода, а ещё и от пряморукости прогера. Очень легко сделать код запутанным, с хитровымудренными ветвлениями
   Сияющий в темноте
 
335 - 04.10.20 - 18:13
не все можно покрыть тестами.
тесты мелких алгоритмов помогают тогда,когда у алгоритма есть граничные точки,в которых поведенте алгоритма нужно обязательно проверить-просто-при тестировании всего блока может оказаться,что условия выхода на точку очень сложно подобрать.
в остальных случаях,тестирование кусочков-это лишняч трата времени,особенно,если кусочки оперируют объектами,и создание и заполнение объектов в тесте-это не так просто.
опять же,если программист пишет код и полностью понимает,как он работает,то тесты не нужны.
и очень печальная ситуация,когда проблема в архитектуре,что в 1с чаще всего,тогда все кусочки работают правильно,и конечно пройдут тесты,если таковые будут,а вот общий результат тест не пройдет.
   Сияющий в темноте
 
336 - 04.10.20 - 18:16
и по поводу 20 лет TDD
в старых системах,написанных на Си,каждая функция была вынесена в отдельный модуль,и очень часто снизу был написан код для проверки этой функции,так что явно не 20 лет.
   Конструктор1С
 
337 - 04.10.20 - 18:34
(336) так и полиморфизмом, инкапсуляцией и в некотором роде наследованием сишники пользовались ещё задолго до изобретения ООП. Но тогда это было уделом лишь некоторых профессионалов, а разработчики ООП двинули полиморфизм, наследование и инкапсуляцию в массы. Тут что-то подобное
   ДенисЧ
 
338 - 04.10.20 - 18:40
(336) "каждая функция была вынесена в отдельный модуль"

https://www.youtube.com/watch?v=l_--ewb4YXg
   novichok79
 
339 - 04.10.20 - 23:18
(287) JUnit - не панацея. ок, 1С придумает JUnit, сделают новый базовый класс МД, то есть добавлять тесты в дерево метаданных, или у обработки какой-нибудь добавят свойство в метаданных, что это типа тестовая обработка. от этого мало что поменяется от текущего положения вещей.
далее - например имеем есть гос. веб-сервис, у которого не работает тестовая среда. тестируем на проде - что в 1С, что в Java, ситуация аналогичная будет.
   novichok79
 
340 - 04.10.20 - 23:19
в теме имеет место быть ментальная мастурбация, на языки программирования общего назначения. ну, 1C - не Java, не С++, надо принять это и жить дальше.
   Tonik992
 
341 - 04.10.20 - 23:30
Не нужон он ваш этот TDD в 1С.
   Конструктор1С
 
342 - 05.10.20 - 03:37
(339) JUnit всего-лишь пример. А так модульное (юнит) тестирование уже везде и всюду. Даже в сраном древнем COBOLе уже есть юнит-тестирование
https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_9.5.1/com.ibm.etools.rdz.zunit.doc/topics/t_unit_test_cobol_data.html

(340) а что, если 1с не язык общего назначения, то на неё стали действовать какие-то особые принципы в разработке?
   Стаканов
 
343 - 05.10.20 - 07:04
(329) Так тут никого нет против тестов в целом, но тема то про 1С :))
   МимохожийОднако
 
344 - 05.10.20 - 07:15
(343) Бесполезно объяснять.
   MadHead
 
345 - 05.10.20 - 07:49
Мне кажется что в первую очередь играет культура разработки. Я даже мануальных тестировщика в 1с почти не встречал. Как правило льют сырой код в прод потом уже исправляют баги по мере возникновения. И многих это устраивает как со стороны заказчика так и со стороны разработчика. Такая культура связана с дешевезной сектора 1с. Если компании нужна надёжность высокая доступность сервисов то на 1с вряд-ли будут писать.
   Конструктор1С
 
346 - 05.10.20 - 08:15
(345) да, культура разработки у нашего брата 1сника низка. Но связано это не с дешевизной 1с, а просто с незнанием и неумением. С опозданием до 1с современные методики разработки доходят
   Mikeware
 
347 - 05.10.20 - 08:40
(346) пытались же еще для 7.7 энтузиасты продвигать юнит-тестирование. в массах - не взлетело.
ну и пишут что-то большое (т.е реально занимаются разработкой) - единицы (сама 1с, да крупные франчи), остальные делают мелкие доработки. поэтому пока 1с не сделает инструмент - всё так и будет продолжаться... Официальная методология 1с - не TDD, а ХХП.
   ДенисЧ
 
348 - 05.10.20 - 08:42
(347) ХПП? )))
   Конструктор1С
 
349 - 05.10.20 - 08:50
(348) Хуяк, хуяк и в продакшн™
   Конструктор1С
 
350 - 05.10.20 - 09:06
   MadHead
 
351 - 05.10.20 - 09:07
(346) Связываю культуру разработки с ценой ошибки. На 1с в большинстве случаев цена ошибки в коде не достаточно велика что бы хотя бы нанять тестировщика, который по тест плану прийдется и все проверит.
Сам не являюсь фанатом TDD и на мой взгляд сделать интеграционное тестирование сквозного функционала проще. Подняли 1с проинициалтзировали базу файйловую, а дальше создаём к примеру справочник из json/xml и результат обратно в json/xml и сравниваем с эталоном, можно наверное сделать такое через ВЭБ сервисы или АПИ веб клиента
   Mikeware
 
352 - 05.10.20 - 09:09
(349) (350) Истину глаголишь!
   Mikeware
 
353 - 05.10.20 - 09:13
Я вот пытался разобраться с юнит-тестированием, применить его (в клюшках еще), но понял, что  разработчику, скажем, класса ПоставщикДанных - это необходимо (ну по крайней мере - полезно), а "разработчику" поделок на его основе (т.е мне) - скорее всего выйгрыша не будет.
   novichok79
 
354 - 05.10.20 - 17:32
(342) 1C - это предметно-ориентированный язык, он сделан чтобы автоматизировать учет. все остальное допиливается по остаточному принципу.
   Конструктор1С
 
355 - 07.10.20 - 05:58
(354) так не потому что это объективный подход, а потому что "так исторически сложилось". У 1сников пока что низковатая культура разработки
   Галахад
 
356 - 07.10.20 - 08:09
Полезная статья: http://catalog.mista.ru/1c/articles/1056335/

Особенно глава : На что стоит писать Unit-тесты и что это дает
Похоже тут именно об этом спорили пару страниц.
   Злопчинский
 
357 - 07.10.20 - 08:19
вот открываю я в УНФ диалог выбора типа значения доп.реквизита, поле на форме для задания длины строки - туда можно ввести 1024 (да еще, бть, с пробелом в разделителе разрядов, но это ладно) - тока размер поля такой что видно "1 02" да и двойка наполовину обрезана. Спрашивается - какие пидарасы (в хорошем смысле слова) это делают?!
   Злопчинский
 
358 - 07.10.20 - 08:21
..возможно это связано с масштабом отображения, настроенном на ноуте 125% (150% тоже частенько бывает, практически норма) - но где тогда гибкость этих гибких экранных форм?! и так, бть, куда ни ткнись - что ни экрначик - то какая-нить жопа...
   Злопчинский
 
359 - 07.10.20 - 08:21
и какое тестирование такой трабл обнаружит как в (357)?
   novichok79
 
360 - 07.10.20 - 09:14
(355) ну... все в наших руках ))
 
 Рекламное место пустует
   Стаканов
 
361 - 07.10.20 - 09:15
(359) Как какое? Пользователями, конечно.
   Галахад
 
362 - 07.10.20 - 09:22
(357) Ну это ж не ошибка, так неудобство.
   Злопчинский
 
363 - 07.10.20 - 21:54
(361) зашибись!
   Злопчинский
 
364 - 07.10.20 - 21:57
нате вам еще шедевров от пейсателей типовых
(учтите, что я даже в процессы не лезу, все по верхам, по самой тривальности)
https://i.ibb.co/KLHvNNJ/2020-10-07-213649.png

ошибка - ДА! я, блин, инвалид, 2 минуты потратил чтобы набить 15 букв. и получаею зае...ый результат!!!

вот если отвлечьсся от того что ПОЛЬЗОВАТЕЛЬ !!!!_ДОЛЖЕН ЗНАТЬ_!!!
ну ведь логично ожидать раз поле для ввода есть, кнопка есть, значит - должен быть ожидаемый результат - найдено или не найдено.
но блин ну никак не то что на скрине
   vis_tmp
 
365 - 07.10.20 - 22:02
(358) Ты совершенно прав. На десктопе при 100% всё показывается точно также, как ты описал.
   Злопчинский
 
366 - 07.10.20 - 22:03
(365) повбывав бы
   Злопчинский
 
367 - 07.10.20 - 22:04
ты на форум по eya зайди - там всякой такой хрени я понаписал вагон
   Полован
 
368 - 07.10.20 - 22:26
(367) Почти как форум по ауе прочиталось :) Адрес какой у форума?
   Злопчинский
 
369 - 07.10.20 - 23:14
   Fram
 
370 - 07.10.20 - 23:27
А почему бы ещё не писать тесты на функции теста. Вдруг там тоже налажал.
Сам использовал ХХП всю жизнь. Потом попал в большую команду, где тесты были обязательны. Проработав так 4 года, понял, что максимум что они могут проверить это что 2х2=4. Зато времени иногда уходит до 90% на эту хрень.
Если бы заказчики понимали это, они никогда бы не согласились платить за это.
   Злопчинский
 
371 - 07.10.20 - 23:30
(370) "А почему бы ещё не писать тесты на функции теста." - это я давно задавал то ли здесь в каких-то ветках, то ли в ИС в аналогичных... ;-)
   Злопчинский
 
372 - 07.10.20 - 23:38
Кстати вот такую хрень как в (364) какойнить тдд/бдд/юнититд - отловит?
причем тест максимально ОТ МЕНЯ независящий. то есть

1. типа "тестируем сценарий полнотекстовый поиск, вводим в строку чтото, нажимаем "искать" - получаем страницу с результатами поиска, если страница не получена = ошибка" - такой тест должен эту хрень отловить.
.
2. но нахера писать такой тест? если блин д.б. тест
"тестируем сценарий полнотекстовый поиск. если GnG = вЫкл - и получается ввод в строку, это - ОШИБКА"...

Вопрос:
какой тест написать - есть правильно: 1 или 2..?
если 2 - это значит при программировании страницы ПтП - кодили полные дебилы (в хорошем смысле слова).
если бы кодили нормальные - то даже теста на такую тривиальную хрень не надо было бы.
.
(задумался про разработку через тестирование)

а это значит - мне как тестировщику - надо блин писать больше и понимать лучше чем эти криворуко-кодеры...
это насколько стоимость разработки/продукта возрастет?
.
нахера таогда всякие ТЗ/ТП и прочая хрень..? сидит команда ХХП, сидит команда тестировщиков (а еще лучше отдать эзверям и назвать это "сценарии прикладного тестирования" ;-) и аджайлит/скрами и канбанит адски... - так что ли?
   DomovoiVShoke
 
373 - 08.10.20 - 00:45
Прочитал тему. Немного взорвался мозг.
Нет в 1с тестов и не надо их там делать, пусть хоть в одной отрасли программисты нормально пишут с головой. А то если еще и 1сники перестанут норм программировать, то кто будет заниматься автоматизацией?
Пишите сразу без ошибок - так лучше, чем писать непойми как и потом еще 100500 тестов такого же качества.
   Конструктор1С
 
374 - 08.10.20 - 04:34
(373) вот как раз 1сники НЕнормально программируют. Пока мелкие задачи всё хорошо, но чуть дело доходит до сложной задачи, начинается трэш...
   Конструктор1С
 
375 - 08.10.20 - 04:47
(373) вот поэтому и жирный плюс, когда разработчик сам пишет тесты. Разраб изначально задумывается, как сделать код линейным, хорошо и легко покрываемым тестом. А не так что выкатил код, а вы тестируйте как хотите
   ДенисЧ
 
376 - 08.10.20 - 05:04
(373) А ёжиками мышам стать не надо?
   Конструктор1С
 
377 - 08.10.20 - 05:06
(370) а это уже вопрос квалификации. Тесты тоже нужно уметь писать. В вашем случае видимо заказчик нужность и важность тестирования понимал, да прогеры не понимали
   Конструктор1С
 
378 - 08.10.20 - 05:07
Господа, вы-то сами как считаете, нормально когда множество ошибок отлавоивается пользователями уже в продакшене?
   PR
 
379 - 08.10.20 - 08:28
А вы все полощете
Ню ню
   Злопчинский
 
380 - 08.10.20 - 11:54
такс. какой тест отловит такую хрень.
УНФ - групповое изменение реквизитов - справочник договоров, Отбор "Контрагент договора в ГРУППЕ ИЗ СПИСКА" - открывается СЗ дл янабора групп (добавить/подбор) - в открывшемся ШТАТНОМ диалоге - нет возможности выбрать группу.
иерархия групп есть - отдельный списочек на форме - но он только для указания элементы какой группы отобразить a форме списка...?

каким тестом это отловить?
   PR
 
381 - 08.10.20 - 11:55
(380) BDD
   Злопчинский
 
382 - 08.10.20 - 11:56
(377) ну так может и программирование - это вопрос квалификации. Код тоже надо уметь писать.
если код не умеют писать нормально, приходится покрывать его тестами. то откуда будут писаться нормальные тесты? не умеют писать коод - внезапно умеют писать тесты? херня-с!
   Злопчинский
 
383 - 08.10.20 - 12:00
(381) и как - я блин должен написать тест "проверить что есть возможность выбрать группу если список открыт для выбора группы"..? еа если список ваще нихрена не знает для чего он открыт? как это описать? "если открыт список для выбора проверить что есть возможность выбора группы"..?
нахера мне такие тесты?
я когда пишу (условно) форму - я пишу ее для конкретной области применения. если подразумевается выбор групп - я пишу форму с возмождностью выбора групп. если я пишу сверху "обертку" которая у меня вызывает форму для (условно) выбора группы - я проверяю - а вообще эта форма такую возможность дает? ) - по сути я сам провожу тест.

в чем цимус этот тест формализовать?
   PR
 
384 - 08.10.20 - 12:02
(383) Да, ты должен сделать тест типа "Я открываю групповое изменение реквизитов, выбираю то-то и то-то, щелкаю отбор, выбираю такую-то группу"
Цимус в том, что если какая-то скотина это поломает, то об этом скажет ночной тест, а не наткнувшийся на это пользователь
   Злопчинский
 
385 - 08.10.20 - 12:10
(384) хреново. мне эту хрень не оплатят. масштабы не те. и думаю во многих конторах также, если не в большинстве.
   Злопчинский
 
386 - 08.10.20 - 12:12
УНФ. Форма списка документов "заказ покупателя" - Еще-Изменить форму - Выключил две галки, включил одну из них - получил ошибку кода.

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

я ЛИЧНО как тетсердолжен перебрать (написать тесты) ВСЕ ВОЗМОЖНЫЕ ВАРИАНТЫ комбинаций всех галок и всех последовательнойтсей манипуляции с ними, чтобы протестировать нормальное поведение формы?
   Галахад
 
387 - 08.10.20 - 12:15
(385) В любой конторе найдется пара-тройка мест, которые достаточно сложны и в которые лезут на так уж и часто, но которые критичны для простоя. Вот их то и стоит обложить тестами. И это вполне окупиться.
   Злопчинский
 
388 - 08.10.20 - 12:30
(386) теперь просто хрен открыть форму списка заказов. основной инструмент менеджера.
тупо валится в ошибку. я хренею с этих пейсателей типовых продакшенов.
   Злопчинский
 
389 - 08.10.20 - 12:30
(387) пока я только матюками могу обложить...
   PR
 
390 - 08.10.20 - 12:40
(386) Все комбинации никакими
Но твой обнаруженный косяк можно добавить в тест
   Конструктор1С
 
391 - 08.10.20 - 13:01
(384) "Цимус в том, что если какая-то скотина это поломает, то об этом скажет ночной тест, а не наткнувшийся на это пользовате"

То же самое делает юнит-тестирование, только эффективнее. А при TDD скотина, поломавшая функционал, узнает об этом ещё на этапе разработки
   Злопчинский
 
392 - 08.10.20 - 13:24
(390) зашибись.
я обнаружил косяк.
добавили в тест.
косяк тут же поправили.
В ЧЕМ ЦЕННОСТЬ ТАКОГО ТЕСТА ДАЛЕЕ? в том что вдруг внезапно через полтора года что-то сложится что приведет к слому того что исправленный косяк исправили еще раз и косяк снова всплыл?
   Злопчинский
 
393 - 08.10.20 - 13:26
(390) хрен с ним со всеми комбинациями.
пусть будут "ключевые" комбинации.
кто будет определять эти ключевые комбинации - Я?!
или может все-таки кодить надо правильно СРАЗУ (похорен как какими инструментами условно пока. главное - правильно).
   PR
 
394 - 08.10.20 - 13:28
(391) Да заканчивай уже что ли
TDD это никогда не обнаружит и правильно сделает
   Злопчинский
 
395 - 08.10.20 - 13:28
кто, бть, должен делать правильно - например если вводится месяц и день что не бывает 30 февраля? я об этом на тестах должен хаботиться или все-таки кодер должен изначально  обрубить такие проблемы при кодинге? а то полувчается - хрен ли думать при кодинге, покроют тестами - где гавно всплывает - тогда и поправим? а сейчас ХХП и норм!
нахрен такой аджайловый/экстремальный подход!!!
   Злопчинский
 
396 - 08.10.20 - 13:30
что могу сказать из своей практики.
пока что я , с типовой ТиС, с кучей своих "костылей" - работается манагерам лучше и беспроблемнее чем, б! типовая УНФ с кучей ХХП-разрабов... преувеличиваю конечно.. но вот как-то так пока у меня впечатление от типовой УНФ... злой я. злопский. хотел в Добропа переименоватся, хрен! буду Злопом.
   PR
 
397 - 08.10.20 - 13:31
(392) В том, что есть вещи, ты не поверишь, которые ломают постоянно
   Стаканов
 
398 - 08.10.20 - 13:31
(391) Ты ещё скажи, что на этапе статического тестирования кода поймает, да :))
   PR
 
399 - 08.10.20 - 13:31
(392) Кроме того, бывают вещи, которые важно, чтобы они работали
А сломать их можно миллиардом способов
   PR
 
400 - 08.10.20 - 13:32
(393) Да, ты
  1  2  3  4  5   

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