Имя: Пароль:
1C
1С v8
v8: Разработка через тестирование и просто автоматическое тестирование. Кто практикует?
, , ,
0 Armando
 
09.06.14
11:12
Поделитесь впечатлениями.
130 artbear
 
10.06.14
02:28
(129) Ты не можешь не знать, как будет выглядеть конечный результат.
Ты все равно примерно представляешь, чего ты хочешь достичь своим кодом.
Т.е. приемочные критерии есть всегда, только часто в неформализованном виде.
Если видение конечного результата у заказчика достаточно размыто, можно использовать механизм итераций - мы реализуем для заказчику одну полезную фичу, демонстрируем, заказчик дает обратную связь и понимание цели улучшается как у заказчика, так и у разработчика.
Часто бывает так, что после первой итерации разработка идет совершенно в другом направлении, чем было заявлено в начале :)
Это вообще схемы Agile и гибких технологий.
ТДД здесь удобен тем, что ты не пишешь большой, сложный и конечный тест,а пишешь тест на маленький/небольшой функционал, который можно быстро реализовать и проверить.
131 artbear
 
10.06.14
02:31
(128) Легаси-код плох именно тем, что его менять страшно. Упасть может что угодно, заранее очень сложно сказать, что, где или когда упадет.
132 Asmody
 
10.06.14
02:32
Могу привести пример с мистой. Вздумалось мне отрефактоиить модуль, который парсит сообщение, выделяет ссылки, ники и т.п.
Я по науке написал пачку юнит-тестов, на каждый случай отдельно, на всякие сочетания, на все вместе, погонял на старом коде, работает.
Потом начал рефакторить. В процессе пришлось пару раз переписать тесты, поскольку у меня изменилась логика вызовов.
В результате все тесты проходят, но я знаю как минимум 4 бага при разборе сообщения. 3 случая были непокрыты тестами, а в одном ошибка вообще "плавающая".
Но разницы до и после никто не заметил, разве что работать стало побыстрее
133 artbear
 
10.06.14
02:33
Добавлю к (130)
Почти всегда лучше юзать механизм итераций, как в разработке, так при решении других задач.
Например, я юзаю технику Pomodoro (Помидор) для выполнения каждодневных задач, не только при разработке :)
134 artbear
 
10.06.14
02:37
(132) При изменении функционала тесты могут начинать падать. Это нормально.
Нужно понимать, в чем причина падения тестов:
1. что-то поломали.
2. тест устарел и его нужно либо исправить, либо вообще удалить. Скажу по себе - сложно удалять тесты, жалко свой/чужой/накопленный труд, но "скрепя зубы" делать это нужно.

Есть даже понятие "хрупкость тестов" - когда при небольших исправлениях приходится менять много тестов.
Если приходится часто переписывать тесты, возможно, они "хрупкие" :( Например, они очень сильно зависят от каких-то частностей, деталей реализации и т.п.
135 Asmody
 
10.06.14
02:37
(131) легаси-код отличается тем, что обычно он просто есть. А ресурсов и желания покрыть его тестами, отрефакторить, да просто причесать обычно нет. Т.е., "работает - нет рожь" до первого чиха.
136 artbear
 
10.06.14
02:40
(132) "Разницы никто не заметил"
1. Либо эти кейсы встречаются очень редко
2. Либо для пользователя эти баги не критичны
3. либо тех.поддержка никакая и эти баги не чинит, а пользователи уже задолбались о них писать. А в отсутствие обратной связи от поддержки пользователю надоедает писать об одних ошибках.
По-разному бывает.
137 artbear
 
10.06.14
02:41
(135) Я юзаю принцип бойскаута "После меня должно стать чище". При любой возможности стараюсь слегка причесать код.
Я перфекционист, приходится себя удерживать, чтобы не погружаться слишком :)
138 Asmody
 
10.06.14
08:38
(136) в конкретном случае речь шла про модуль парсинга сообщений на этом форуме. Он используется всякий раз, когда кто-то нажимает кнопку "Отправить"
139 Asmody
 
10.06.14
08:38
(137) если перфекционизм оплачивается из своего кармана, то почему бы и нет?
140 Steel_Wheel
 
11.06.14
01:22
(138) я там пару багов видел, кстати ))
нужно куда-нибудь сообщать?
141 France
 
11.06.14
01:47
(0) я практикую.. и на проектах пытаюсь проталкивать - но понимания практически не нахожу..
Зы.. по другому, собственно, и быть не может..
142 ILM
 
гуру
11.06.14
06:11
Тест есть только в сложных расчетных динамических алгоритмах. Там где формул много и когда куча запросов в пакетах. В остальном и без него хорошо получается.
143 Armando
 
11.06.14
11:23
(141) >> но понимания практически не нахожу
Почему?
144 tenikov
 
11.06.14
11:27
(0) я практиковал (когда разрабатывал), мне вообще иделология XP нравилась.
145 Господин ПЖ
 
11.06.14
11:35
(141) сатрап
146 Kraft
 
11.06.14
16:53
147 Armando
 
11.06.14
21:37
(146) почитал. муть какая-то.
148 Злопчинский
 
11.06.14
22:58
...чувствую себя тупым и отсталым...
149 1с-кин
 
11.06.14
23:15
(0) Изначально гнилая идея в 1С.
Объясняю: чтобы писать "тесты" в 1с наравне с функционалом, код "тестов" будет занимать 3 к 1 по отношению к коду функционала. И 80% времени разработки.
Все, что зедсь наобсуждали - обсуждение сферического коня.
Все, что нужно - это при разработке максимально:
- встроить обработку ошибок (вопреки методологии 1с)
- придумать и проверить разработку на всевозможных вводных
- детальнейше задокументировать функционал и что-куда вписано кодом.
А тесты в 1с - это игрушки. Меняются исходные данные - нет обработки ошибок - все "тесты" вместе с функционалом идут в лес.
150 1с-кин
 
11.06.14
23:19
.. что такео "моки"?
и вообще - куча сокращений и "типа умные слова", и ни одного объяснения.
Хоть один кто знает, что за "TDD" и "MVC"?
151 1с-кин
 
11.06.14
23:27
(92) Вот что это - 1CUnit - можете пояснить? Методология, применение, цели? Для чего вообще затеяно?
152 Steel_Wheel
 
11.06.14
23:49
(150) Ну, я знаю. И че?
153 1с-кин
 
11.06.14
23:51
(152) знал бы, писал человеческим языком )
154 1с-кин
 
11.06.14
23:52
(152) что означают в данном контексте все эти буковки? Зачем они здесь? Какое имеют отношение к разработкам на 1С?
155 Steel_Wheel
 
12.06.14
00:28
(154) ТС хочет реализовать и популяризовать "Разработку через тестирование" на платформе 1С. При разработке с помощью других средств программирования этот подход себя показал вполне жизнеспособным. ТС решил, что и с 1С взлетит.
156 1с-кин
 
12.06.14
00:42
(155)"ТС решил, что и с 1С взлетит."
Как "оно" все может взлететь, если в 1С нет никаких встроенных средств тестирования и проверки, подходящих под обсуждаемые? И все надо делать врукопашную. У кого есть время и желание. Причем заплатят только за "20% функционала".
157 Steel_Wheel
 
12.06.14
00:44
(156) Я не могу держать ответ за ТС :)

Но, кажется, он 1с-юнит запилил
158 Адский плющ
 
12.06.14
01:08
Разработка через тестирование это тот самый рак, что на безрыбье, т.е. в условиях отсутствия вменяемого ТЗ.
Т.е. в рамках отсутствия четких функциональных требований к системе, программист определяет для себя ряд тестов, прохождение которых как бы верифицирует код на состоятельность в данной предметной области.
Т.е. слово "тестирование" тут себя не совсем в своей тарелке чувствует. Эти все юнит-тесты в коде не выявляют баги тогда, когда функционал изменяется под новые требования. Спросите почему? Элементарно! Под изменение функционала надо переписывать юнит-тесты. Короче, онанизм в чистом виде. Очередной руп/экспи и прочее серебрянное непотребство.
159 artbear
 
12.06.14
13:28
(157) xUnitFor1C пилил не ТС.
160 artbear
 
12.06.14
13:33
(155) Автоматическое тестирование в 1С давно можно использовать. Методика ТДД универсальна, ей неважно, в какой среде работать.
Автоматическое тестирование давно доказало свою полезность.

Народ, расскажите, как вы поймете, что реализованный вами функционал сделан под требования заказчика?
161 pumbaEO
 
12.06.14
14:26
(160) Зачем спорить... Теоретики уже для себя решили, что им тестирование не нужно.
162 Fragster
 
гуру
12.06.14
14:36
(160) время написания теста не меньше времени написания функционала. только еще дополнительно и в тесте накосячить можно, а все варианты исходных данных для всякой лабуды типа скидок и всяких переделов не напишешь..
163 artbear
 
12.06.14
16:02
(160) Согласен. Но хочется же помочь людям повысить свою квалификацию, качество своих продуктов и увеличить свою производительность.
164 Адский плющ
 
12.06.14
16:36
(160) "Народ, расскажите, как вы поймете, что реализованный вами функционал сделан под требования заказчика?"

Паяльником выясняешь что хочет заказчик, а потом сравниваешь это со своей поделкой.


Хотя, если бы 1С-ники применяли автоматическое тестирование, они бы позорно не выпустили релиз ERP, в котором не открывается форма элемента Вида номенклатуры.
165 artbear
 
12.06.14
16:43
(164) >>Хотя, если бы 1С-ники применяли автоматическое тестирование, они бы позорно не выпустили релиз ERP, в котором не открывается форма элемента Вида номенклатуры.
.
Да, 1С периодически этим отличается :( Сталкивался и на 77, и на 8.Х
.
Я в xUnitFor1C специально для проверки выхода изменений, нового релиза конфигураций сделал "дымовые" тесты открытия различных форм конфигурации (элементы справочников, документов, списки, отчеты, обработки) для ОФ и УФ.
На наших проектах после введения автотестирования открытия форм конфигурацию вероятность такого бага стремится к нулю :)
166 Злопчинский
 
12.06.14
16:55
(165) меня сильно интересует наскольо TDD увеличивает трудозатраты на выпуск рабочих вариантов на начальном этапе его применения...? стоит ли этим заморачиваться?
167 Armando
 
12.06.14
18:57
(166) По отзывам до 50% времени. Потом меньше.
168 spock
 
12.06.14
19:41
(166) Наоборот сокращает общее время. При TDD меняется подход к программированию.
169 Armando
 
12.06.14
19:58
Кстати xUnitFor1C нашел пару багов тестом открытия форм
170 pumbaEO
 
12.06.14
22:59
(169) а автоматизированная проверка конфигураций (от 1С) разве не находит те же ошибки?
171 Armando
 
12.06.14
23:20
(170) хз. Я пока забросил. Как разберусь с вопросом v8: Как программно получить правило поддержки объекта? так продолжу. Пока не до этого. Надо тестирование запускать, а то туго становится, не углядишь за всем и всеми.
172 Лефмихалыч
 
12.06.14
23:23
(160) >как вы поймете, что реализованный вами функционал сделан под требования заказчика?
хм... я сначала позырю требования в ТЗ и сравню с объективной реальностью, данной мне сначала в коде, потом в тестовой хоне. Далее - отдам поделие БиАй-у, который ТЗ писал, на опытную эксплуатацию.
А как в этом поможет TDD?
173 Лефмихалыч
 
12.06.14
23:24
(170) неа, оно поведение не проверяет. Оно проверяет оформление
174 Лефмихалыч
 
12.06.14
23:27
ОФФ:(171) я вот, кстати, третьего дня тем же вопросом задался... пока одно разочарование
175 Armando
 
12.06.14
23:32
176 Лефмихалыч
 
12.06.14
23:34
(10) это ты лучше artbear и pumbaEO послушай - они TDD, на сколько я понимаю, на практике применяют в промышленных масштабах.
177 Armando
 
12.06.14
23:34
(174) Ну там глазами вроде понятно как и что, надо только придумать как это распарсить. И что конкретно содержится в файле GUID.4
178 Лефмихалыч
 
12.06.14
23:34
(175) да - к тому, что на 8.0 не взлетит :)
179 Armando
 
12.06.14
23:37
(176) Артур тут уже нормально отметился + в скайпе общаемся по тестам.
xUnitFor1C себе вкрячил с тестом открытия форм. Думаю че дельше с этим делать.
180 Armando
 
12.06.14
23:46
(174) Кстати, свистни, если докапаешься до истины
181 Лефмихалыч
 
12.06.14
23:58
фух, прочитал. ПО поводу нытья: "а как же мы хитровыпученные слууучаи тестить будем, да как мы закрытие мееесяца" и прочая хунта. Да как напишете, так и будете. Взять, к примеру, ДО КОРП - он наглухо не подлежит "из коробки" ни какому автоматному тестированию, т.к. там овер 146% кода, которому месту в модуле, находится в форме. Но это не всё не аргумент против ТДД. Это вообще не аргумент.
Да, будет код, который в том виде, в котором его выделил из себя программист, ни какими тестами не покрыть - только матом. Это просто означает, что код надо будет писать соответствующим образом и все. Да, проблема с тестом туповых, отраслевых и прочего фуфла от сторонних разработчиков ни куда не девается, но хотя бы свой код можно и пасть правильно, и тестить автоматно - это уже будет здорово и офигенно. Существующая же практика тестирования биаями и прочими пользюками порочна наглухо - любой присутствующий в этой ветке это знает на своем собственном опыте. Даже те, кто говорит: "и как нам это" или "как нам то". Да, тест может содержать ошибки, но именно по этому их должно быть больше одного. А с ручным тестированием ни чего не сделаешь - даже массовые расстрелы или неистовые премирования могут только временно увеличить эффективность. И вы все об этом знаете, господа.
182 Лефмихалыч
 
13.06.14
00:09
особенно омерзительны аргументы типа "где мы возьмем время, чтобы тесты писать?"
Да там же, где вы его берете, когда делаете вот это тестим-правим-тестим-правим постоянное!

или "где нам тестовые данные брать" и "это же тестовую зону готовить - целая работа"
а, ***ть, так вы эту работу не делаете, да? Подумайте так же о том, что ТДД дает возможность сэкономить овер дохрена времени на экстренных обговлениях. Да, вы в это время не пузо чесать будете, а тесты писать, но зато в результате, когда вы "чик-чик и в продакшн", оно просто берет и работает прямо сразу.
183 Armando
 
13.06.14
00:21
(181) (182) Мощно задвинул, внушает)
184 pumbaEO
 
13.06.14
00:31
(179) анализировать. Весь то прикол, в автоматизации этих всех проверок и сообщать тревожным звоночком - "барин, все пропало, обмены застопорились, ниче не работает. Кароч, ж полная вертай свои правки обратно. "
185 Лефмихалыч
 
13.06.14
00:44
моя версия:
http://i.imgur.com/W5nZEpG.jpg
186 Лефмихалыч
 
13.06.14
00:59
мешает только неготовность IDE к этому. Конфигуратор готов к TDD в той же мере, в какой он готов к коллективной разработке: теоретицски - это лошадь, но практицски - она падает (с)
187 pumbaEO
 
13.06.14
09:35
(186) Написал тест, сохранил, в снегопате на горячую клавишу повесил вызов Предприятия и запуск обработки с тестами (там всего указать путь к запуску обработки и параметры обработки для автоматического запуска тестов), посмотрел результат и т.д.

p.s. без снегопата надо придумывать F5, Alt+Ф, 1 и уже автоматом запустилась обработка.
188 artbear
 
13.06.14
11:54
(170) Женя, АПК (Автомат.проверка конфиг-й) вообще не проверяет поведение.
Основная задача тестирования открытия форм - проверка поведения, аналогично тому, как работает у пользователя.
189 Armando
 
15.06.14
21:27
Кстати, кто интересовался как тестировать отчеты?
здесь https://github.com/xDrivenDevelopment/xUnitFor1C
уже есть рабочий пример с тестом отчета на СКД
190 1с-кин
 
17.06.14
00:21
(181) не получится никак.
Как можно тестить то, чего не знаешь?
Что потребуется завтра?
(188)>>Основная задача тестирования открытия форм
Открываешь форму - работает. Не открывается - не работает. Как тест проверит, открывается форма или нет? Я если я её из кнопки через зад в отчете через обмены открываю?? Откроется??
(161)>>Теоретики уже для себя решили, что им тестирование не нужно
если "теоретик" - я, то сообщение выше - ерунда. Тестиррование НУЖНО. Но 1С всячески этому сопротивляется.
А 1Сникам только этого и нужно - делать меньше, думать меньше.
Внес изменения - проверь ВСЕ. Еще раз ВСЕ. И напоследок ВСЕ. Потом - в продакшн. И еще раз проверь и исправляй по звонкам.
И как тут помогут тесты??
А то "формы открыть" ... Ну так открой вручную ))
У вас что - на все формы всех объектов тесты написаны? А если через "зад" форма открывается?
191 Asmody
 
17.06.14
00:31
Тесты-тесты-тесты... херня это все. Я сегодня три часа убил на то, чтобы доказать продажникам, что БП считает НДС в СФ правильно, а не так, как им хочется. Последним и решающим аргументом в споре с их стороны было: "это большой и важный клиент, и у НИХ программа требует, чтобы всегондс сходилось с всего до копейки." (Клиент - это "Ростелеком" на секундочку). И пи.дец
192 1с-кин
 
17.06.14
00:33
(160)>>расскажите, как вы поймете, что реализованный вами функционал сделан под требования заказчика?
Прочитаю все, что удалось наскрести по ТЗ. Напридумываю всяческих ситуаций вплоть до вторжения инопланетян и появления у них желания воспользоваться нашим новым функционалом.
Проверю. Проверю еще раз. Смешаю данные. Снова проверю. Прикинусь дураком (т.е. пользователем, конечно). Проверю. Добавлю защиту "от дурака". Проверю.
Возьму ситуацию, что все взорвалось, и на вход в обрабтку поступают даже не данные, а мусор. Сделаю обработку ошибок. Проверю обработку ошибок.
Прикинусь пользователем. Сделаю ему рельсу, где необходимо и возможно. Остальное заблокирую или хотя бы предупрежу.
Проверю.
Напишу и объясню, как пользоваться.
Прикину, как лучше исправлять ошибки и чем их проверить.
Подожду звонков с ошибками.
Исправлю.
Проверю.
Снова подожду звонков с ошибками.
Цикл несколько раз.
Сдаю в продакшн.
А вы тут тесты какие-то обсуждаете... Тесты оттестировать даже функционал не могут, потому что непредсказуемо поведение программы в 1С.
А уж будущие изменения и подавно.
193 1с-кин
 
17.06.14
00:38
(191)>>и у НИХ программа требует
во-во, "программа ТРЕБУЕТ"...
Т.е. хотелки дают пользователи, а требует - ПРОГРАММА. И расшибись хоть с тестами, хоть без тестов, между пользователями и желехобетонром "программа ТРЕУБЕТ"...
194 1с-кин
 
17.06.14
00:38
*железобетоном. Скалой.
195 Asmody
 
17.06.14
00:41
(182) я сейчас большую часть времени занят немного не программированием, но в параллельной инженерной области. Так вот, если туда перенести идеологию ТДД, то перед проектировкой, монтажом и настройкой системы, необходимо построить рядом систему на порядок сложнее, которая будет тестировать поведение основной системы, причем, на все вероятные и невероятные случаи. Это бред. Там, где традиионная инженерия обходится мониторингом, коррекцией и резервированием, прграммисты изобрели своего слона и с усердием на него моляться.
196 Asmody
 
17.06.14
00:42
Мягкий знак не нужен
197 1с-кин
 
17.06.14
00:43
(113)>>Работа в 1С - это по большей части сопровождение продукта, а не выпуск совершенно нового функционала.
конечно... только 90% одноэсником в меру способностей именно тем и занимается - что переписывает и перелицовывает типовые "под нужды компании".
А есть "счатливчики", которым задача стоит с нуля конфу написать. Чтоб, типа, и не УПП, но бухгалтерия и склад работали, и менеджеров не забыть.
198 Asmody
 
17.06.14
00:44
Кроме того, так никто и не ответил на вопрос: надо ли тестировать тесты?
199 1с-кин
 
17.06.14
00:47
(182)>>Да, вы в это время не пузо чесать будете, а тесты писать,
ну напишешь ты эти тесты... а через месяц не то, что тесты - функционал уже не нужен. Работал я в такой компании - там писались бесконечные отчеты из месяца в месяц, и бесконечные изменения типовой под них. Даже отдельные конфы забабахали, и то не помогало. Типа, "коньюктура требует постоянно нового".
Обработка ОШИБОК на уровне платформы - и все эти тесты скопом можно выкидывать.
А вот этого самого главного и нет. А одноэсники лентяи.
200 1с-кин
 
17.06.14
00:48
(195)>>необходимо построить рядом систему на порядок сложнее
TDD-щики, апологеты, этого не понимают - видимо, под "тестами" и прочим "TDD" они понимают что-то другое... ))
201 1с-кин
 
17.06.14
00:51
(198)>>надо ли тестировать тесты?
а зачем тестировать тесты, если никто не может ответить, что тестируют тесты первого ряда? ))
Ну вот кто-то сообразил - "давайте тестировать открытие типовых форм, а то 1с часто "забывает" проверить работу нового функционала в старых "штанах", и зачастую старый "проверенный" функционал перестает работать из-за "нововведений".
202 Лефмихалыч
 
17.06.14
01:25
(195) и это аргумент против ТДД? Нет. Это ты в очередной раз доказал, что разработка ПО - это не строительство, не животноводство, не растениеводство и не все остальное, кроме разработки ПО.
203 Лефмихалыч
 
17.06.14
01:29
(199) ты смешал в кучу проблему качества техзадания, отсутствия ответственности за экономический эффект от внедрения и инструмент для автоматического тестирования. В результате получилась полная фигня. Но это не потому, что какой-то из этих трех компонентов - фигня, а потому, что когда смешиваются в кучу кони и люди, фигня завсегда получается сама собой. Вселенная так устроена.
204 Лефмихалыч
 
17.06.14
01:32
(198) как хочешь. Ни где гвоздями не прибито - ты можешь тестировать тестами, что угодно, если заняться решительно больше нечем
205 Злопчинский
 
17.06.14
02:08
не... было бы хорошо провести мастер-класс разработки какой-нить простенькой конфы на 2 часа программирования через ТДД - получится как раз рабочий день с ТДД, ответами на вопросы и прочей хренью.
/
возможно ТДД имеет смысл при промышленной разработке. когда есть план, можно покурить, день-два ничего не решают в сроках. то есть когда ИТ занимается РАЗРАБОТКОЙ программного продукта.
/
нихз непонятно...
206 Armando
 
17.06.14
03:05
(205) На ютубе видел примеров + в каких-то блогах. Тока там не 1С. Но тоже понятно. Хотя на 1С было бы привычнее. Я понял, что пока не ТДД хочу. Хочу чтоб в отделе тесты писать хотя бы начали. Потом ТДД.
207 Armando
 
17.06.14
03:06
(198) это называется троллинг)
208 artbear
 
17.06.14
13:14
(205) мы с товарищем проводит такой мастер класс у себя в компании :)
уже 3 тренинга было, в след.среду 4-й будет
209 artbear
 
17.06.14
13:15
Ребята, отрицающие автотесты, и уходящим в троллинг, могу сказать только - тестируйте всегда вручную и не мешайте остальным повышать свою производительность и качество своей работы/своих продуктов.
210 artbear
 
17.06.14
13:20
(195) Еще раз - ты же не пытаешься при ручном тестировании найти все ошибки, верно? это напрасный труд.
Автоматическое тестирование - это улучшение ручного тестирование, это помощь нам/разработчикам в упрощении рутины тестирования.
Поэтому пиши/создавай только те тесты, которые ты можешь сделать, на которые готов потратить время, и те тесты, которые ты считаешь полезными/важными.
211 artbear
 
17.06.14
13:22
(198) "Тестировать тесты" - в процессе создания теста ты и так  должен проверять. У тебя же есть приемочные критерии, у тебя есть понимание требований задачи, у тебя есть примеры от бизнеса - все это помогает сделать "правильный" тест.
Еще раз: Автотест - это только повторение ручного теста, только его можно запускать повторно когда угодно и сколько угодно раз.
212 РенеДекарт
 
17.06.14
17:40
А что реального можно протестировать автоматическими тестами? Есть доводы целесообразности?
213 Armando
 
17.06.14
18:58
(212) 1. Что считаешь нужным, то и тестируешь.
2. Тестировать каждый раз вручную, или тестировать автоматически.
214 Armando
 
17.06.14
21:07
(208) Надо расширять аудиторию. Вебинар, например.
215 artbear
 
18.06.14
20:36
(212) Если подразумевается вопрос "что можно протестировать без ручного создания этих тестов", тогда ответ "мало что можно" :)
Автотесты - это оптимизация и расширение ручных тестов. Если у  вас нет мыслей, что можно протестить вручную, тогда и автотест не сделаете.
Но мы всегда знаем, что можно протестить/проверить, хотя бы что-то простое и элементарное.
.
В продолжении ответа "мало что можно" могу предложить/порекомендовать на своих тестовых баз позапускать тесты открытия всех форм конфигурации( формы списков, элементов, документов, отчетов, обработок и т.д.) в сеансах разных пользователей (админские и ограниченные права).
Формы просто открываются и закрываются штатным образом, без всяких параметров, как будто их открыл пользователь. Работают как обычном приложении, так и управляемом (тонкий и толстый клиент), формы обычные и управляемые.
.
Находятся самые неожиданные ошибки :)
Каждый, кто запустил этот набор тестов, нашел минимум одну проблемную форму.
.
Все это есть в xUnitFor1C https://github.com/xDrivenDevelopment/xUnitFor1C
216 Armando
 
18.06.14
22:52
(215) Каждый, кто запустил этот набор тестов, нашел минимум одну проблемную форму
Подтверждаю)
217 Злопчинский
 
19.06.14
00:06
Создание тестов вручную - путь в никуда имхо.
Еще в бытность мою обучения рассматривались проблемы верификации программного кода.
218 Asmody
 
19.06.14
01:16
(207) да никакой это не троллинг! Почему апологеты ТДД не допускают наличия ошибок в тесте? Функциональные или интеграционные тесты могут быть весьма нетривиальными.
Как убедиться в том, что тесты тестируют правильно?
219 artbear
 
19.06.14
01:35
(218) Ошибки могут быть везде.
Алгоритм формирования тестовых данных и действия, как правило, проще, чем тестируемый алгоритм.
Начинать нужно с малого, а не пытаться сразу создавать большой/сложный тест, который может быть сделан неправильно.
По опыту - тест также нужно проверять, но это намного проще, чем тестирование рабочего функционала.
"Апологетов" ТДД здесь нет, есть люди, которые прошли этот путь и нашли его удобным, мощным, мотивирующим, производительным.
ТДД предлагает сначала написать тест, убедиться в его правильности, убедиться, что он не проходит, и только тогда писать код под него.
Если положительный тест проходит сразу после написания, то либо он ошибочен, либо уже есть функционал, реализующий шаги теста, и не нужно писать новый функционал :)
220 artbear
 
19.06.14
01:38
(217) "Создание тестов вручную" - один из возможных вариантов повышения качества кода, но не единственный.
Нужно юзать и ручное тестирование, работу с требованиями, работу с дефектами, и ревью-кода, и кросс-тестирование и прочая... В т.ч. и верификация кода, которую нам также читали в институте, и по которой куча прочитанных книг была в свое время.
Здесь фишкам в том, что тестировать все равно приходится, это довольно рутинная вещь, которая занимает кучу времени, и поэтому часть работы можно автоматизировать.
221 Злопчинский
 
19.06.14
02:01
вот внедряю вмс сейчас - ну так точно прогеры там вообще ни о каком тестировании не слышали. чел, через которого проходит работа - вручную что-то отлавливает. а я просто - беру NCL? врубаю обработку и начинаю тыкать подряд во все ШК которые вижу... - вот тут и начинается самое интерсеное ;-).
.
неплохо бы еще фейсы тестировать на внятность надписей/мыслей. иногда такое написано, что ни спервого ни со второг раза не разберешь... - как это покрыть юнит-тестами или как там у вас это правильно?
222 artbear
 
19.06.14
15:01
(221) неплохо бы еще фейсы тестировать на внятность надписей/мыслей. иногда такое написано, что ни спервого ни со второг раза не разберешь... ?
Не совсем понял, но попробую ответить:
Это называется "управление требованиями".
Должен быть первый порог - сначала нормальная анализ, отсекаем бред, понимаем, что реально нужно пользователю.
Важно - что нужно отличается от того, что он хочет! :)
После прохождения анализа уже можно идти дальше, к проектированию и реализации.
223 artbear
 
19.06.14
15:03
(221) Это нормально и верно. Первый этап часто ручное тестирование.
Вот когда его становится много/долго, тогда уже можно думать об автоматизации.
"Тыкаю во все подряд ШК" - сколько раз ты будешь так тыкать?
два раза по 100 тыков/пять по 100 тыков/десять по 100 тыков (уже 1000 тыков) ?
потом тебе надоест и ты либо перестанешь это делать (к сожалению, самый легкий и неправильный путь), либо автоматизируешь эту проверку :)
224 Armando
 
19.06.14
23:31
(218) Ошибки в тестах не исключены. Вот ты вручную все тестируешь? Безошибочно?
225 Лефмихалыч
 
20.06.14
23:58
(218) гораздо более интересны два других вопроса:
1. почему антагонисты ТДД считают, что его апологеты не допускают наличия ошибок в тесте
2. почему антагонисты ТДД считают, что ручное тестирование (особенно в условиях, когда алгоритмы нетривиальные) гарантирует более качественную и всестороннюю проверку функционала на соответствие требованиям ТЗ, чем автоматные тесты
226 РенеДекарт
 
23.06.14
13:20
Вот мне нужно знать, что не запустится у пользователя после типового обновления.
Часто проблемы с отсуствием прав.
И что я должен тестировать?
227 ДемонМаксвелла
 
23.06.14
13:28
(226) первое что приходит в голову - проводятся ли  документы, которые вводит пользователь, под его ролью. Может не хватать прав на регистр какой-нибудь.
228 Armando
 
23.06.14
14:15
(226) Вручную ты бы это как тестировал?
229 artbear
 
23.06.14
16:34
(226) Для решения подобных проблем я и добавил в xUnitFor1C возможность открытия форм конфигурации под различными пользователями, и совместно с открытием форм тесты создания или изменения/проведения справочников/документов.
Эти тесты уже помогли нескольким проектам.
Тесты открытия форм достаточно универсальны.
Можно запускать для любого пользователя (админ, не админ) и искать ошибки.
Также есть автотесты создания пользователей с нужным набором прав и автооткрытия форм для него - здесь немного придется допилить макет для описания данных пользователя.