|
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
|
(172) Ты после v8: v8: Экстремальное программирование и 1С. И хочется и колется... пришел к чему-нибудь?
|
|||
176
Лефмихалыч
12.06.14
✎
23:34
|
||||
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 возможность открытия форм конфигурации под различными пользователями, и совместно с открытием форм тесты создания или изменения/проведения справочников/документов.
Эти тесты уже помогли нескольким проектам. Тесты открытия форм достаточно универсальны. Можно запускать для любого пользователя (админ, не админ) и искать ошибки. Также есть автотесты создания пользователей с нужным набором прав и автооткрытия форм для него - здесь немного придется допилить макет для описания данных пользователя. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |