Опрос по тестированию решений на 1С:Предприятии 8
Всем привет!
Очень интересно, как мои коллеги тестируют свои разработки на 1С:Предприятии 8.
Если ни одного варианта, подходящего для вашего случая, нет, опишите свой случай в комментарии.
Пожалуйста, попросите ваших коллег, если они не видели опрос, также также поучаствовать в нем.
Если есть время, пожалуйста, ответьте также в комментариях на следующие дополнительные вопросы:
1. Ваш способ тестирования - общепринятый в вашей команде (если вы не один) или ваши коллеги не тестируют/тестируют другими инструментами, методами?
2. Что не удобно в существующих инструментах тестирования и вам хотелось бы исправить/улучшить? (можно пофантазировать)
3. С какими инструментами вы знакомы (пробовали или пытались разбираться)?
Заранее спасибо за участие в опросе и ответы на вопросы!
Значимые результаты опроса проанализирую поделюсь в виде отдельной публикации.
Очень интересно, как мои коллеги тестируют свои разработки на 1С:Предприятии 8.
Если ни одного варианта, подходящего для вашего случая, нет, опишите свой случай в комментарии.
Пожалуйста, попросите ваших коллег, если они не видели опрос, также также поучаствовать в нем.
Если есть время, пожалуйста, ответьте также в комментариях на следующие дополнительные вопросы:
1. Ваш способ тестирования - общепринятый в вашей команде (если вы не один) или ваши коллеги не тестируют/тестируют другими инструментами, методами?
2. Что не удобно в существующих инструментах тестирования и вам хотелось бы исправить/улучшить? (можно пофантазировать)
3. С какими инструментами вы знакомы (пробовали или пытались разбираться)?
Заранее спасибо за участие в опросе и ответы на вопросы!
Значимые результаты опроса проанализирую поделюсь в виде отдельной публикации.
По теме из базы знаний
- Видеозаписи онлайн-митапа "DevOps в 1С: Тестирование и контроль качества решений на 1С"
- Нагрузочное тестирование в 1С:ERP
- Экспертный кейс. Миграция высоконагруженных решений 1С на Linux/PostgreSQL без потерь производительности
- Экосистема 1С:Предприятие: вчера, сегодня, завтра
- Онлайн-курс "Автоматизированное тестирование в 1С". С 6 мая по 17 июня 2024 г. :
Как вы тестируете свои решения на 1С:Предприятии 8 ("свои решения" = "доработка типовой или разработка с "0")
Тестирую вручную сам, согласно моему пониманию правильной работы (ввожу данные/сверяю результат с ожиданием) (85.93%, 336 голосов)
85.93%
Специально никак не тестирую, об ошибках узнаю в основном от пользователей (24.81%, 97 голосов)
24.81%
Тестирование выполняет мой напарник (9.21%, 36 голосов)
9.21%
Пишу и выполняю тесты при помощи собственной разработки для автоматизированного тестирования (3.58%, 14 голосов)
3.58%
Пишу тесты при помощи "1С:Сценарное тестирование" (1.02%, 4 голосов)
1.02%
Пишу юнит-тесты при помощи SnowTest Федора Езеева (0.77%, 3 голосов)
0.77%
Пишу юнит-тесты при помощи FuncTest.v8 Артура Аюханова (0.77%, 3 голосов)
0.77%
Пишу юнит-тести при помощи "Бизнес-плюс: Выполнение правил проверки" (0.51%, 2 голосов)
0.51%
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
"Тестирую вручную сам, согласно моему пониманию правильной работы"
+
"Тестирование выполняет мой напарник"
Каждый раз, когда наступает время тестировать хочется написать что-то, что хотя бы к минимуму сведет появление новых ошибок, а главное не всплывали старые, а это у нас происходит довольно часто.
Готов оказать помощь по "Тестированию проекта по тестированию" в реальной системе с огромным количеством нюансов. Помощь в разработке обещать не могу, хотя и очень хочется.
+
"Тестирование выполняет мой напарник"
Каждый раз, когда наступает время тестировать хочется написать что-то, что хотя бы к минимуму сведет появление новых ошибок, а главное не всплывали старые, а это у нас происходит довольно часто.
Готов оказать помощь по "Тестированию проекта по тестированию" в реальной системе с огромным количеством нюансов. Помощь в разработке обещать не могу, хотя и очень хочется.
(2) Спасибо, Жень, обязательно воспользуюсь твоим предложением, как только получу работоспособный прототип.
Какого рода места/какой программный код чаще всего "хочется" потестировать?
Пробовал ли SnowTest/FuncTest.v8? Если да, почему не продолжаешь пользоваться?
Какого рода места/какой программный код чаще всего "хочется" потестировать?
Пробовал ли SnowTest/FuncTest.v8? Если да, почему не продолжаешь пользоваться?
SnowTest пытался пробовать, но что-то не заладилось с самого начала. На форуме 1С++ наверное видел мои поползновения: . Там же в соседней ветке я пытался проникнуться идеями и мыслями от Палыча, а он занимается этим с незапамятных времен .
Про FuncTest.v8 что-то ничего не припоминаю.
Не понял вопроса. В идеале хочется покрыть всё )
Еще хочется, помимо результатов выполнения самих ф-ий и модулей, потестировать именно работу пользователя, т.е. Нажатие конкретных кнопок в конкретных формах. Но вообще не представляю как это можно сделать в v8
Про FuncTest.v8 что-то ничего не припоминаю.
Какого рода места/какой программный код чаще всего "хочется" потестировать?
Не понял вопроса. В идеале хочется покрыть всё )
Еще хочется, помимо результатов выполнения самих ф-ий и модулей, потестировать именно работу пользователя, т.е. Нажатие конкретных кнопок в конкретных формах. Но вообще не представляю как это можно сделать в v8
Если честно, я как-то еще не могу увидеть цельную картину того, как это должно работать. Наверное потому что работающих примеров таких систем я не видел. Показывать тоже никто не хочет )
Видел/знаю только со слов уважаемых людей. Но их слова почему-то разнятся. То ли потому что методики тестирования могут быть различными, то ли я так и не созрел для этой темы.
Видел/знаю только со слов уважаемых людей. Но их слова почему-то разнятся. То ли потому что методики тестирования могут быть различными, то ли я так и не созрел для этой темы.
(5) Ты ответил на мой вопрос фразой, что "хочешь покрыть все" :). Я считаю, что именно это желание и губит все благие начинания (сам начинал и бросал в свое время).
(6) Я с тобой полностью согласен, я только что закончил заочный бесплатный курс "Engeneering Long-Lasting SaaS" на , там значительная часть посвящена именно TDD и еще больше BDD (behavior driven development). Там тоже все очень-очень красиво все на слайдах, в видео, и даже в практических домашних заданиях. Но если попытаться взять готовый код, не покрытый тестами и разработанный без учета необходимости тестирования, то уже все совсем не красиво.
Но спешу предупредить, что поднятая тема не является результатом моего эмоционального токсикоза после курса. Я начал копать потихоньку с начала года, после того, как понял, что со Снегопатом часть тестов можно будет запускать из конфигуратора :-). (Кстати, TestRunner.js для Снегопата я писал именно как прототип интерфейса).
Я стараюсь смотреть более прагматично. Я не стремлюсь к TDD, т.е. именно к разработке от тестов. Юнит-тесты - это не обязательно TDD/BDD и прочие красивые аббревиатуры. Я интересуюсь узкой задачей: написание тестов для возможности проверки кода 1С:Предприятия 8 на регрессии после изменений. Причем, уже для готового кода, более-менее приспособленного к автоматическому тестированию, т.к. основная масса его функционала изменяет что-то в одной большой таблице значений.
Я вообще с большим скепсисом отношусь к желанию тестировать все и вся, которое озвучил Женя и которое ко мне тоже приходит. Да, было бы здорово иметь возможность после внесения любого изменения узнать, не сломалось ли чего. Но к сожалению, этот идеал, как и многие другие, не достижим.
Поэтому я хочу довольствоваться малой кровью: иметь возможность писать тесты в тех случаях, когда это целесообразно с точки зрения КПД (с точки зрения отношения степени покрытия тестами часто меняющихся критичных участков кода к усилию на написание тестов и их последующую поддержку).
(6) Я с тобой полностью согласен, я только что закончил заочный бесплатный курс "Engeneering Long-Lasting SaaS" на , там значительная часть посвящена именно TDD и еще больше BDD (behavior driven development). Там тоже все очень-очень красиво все на слайдах, в видео, и даже в практических домашних заданиях. Но если попытаться взять готовый код, не покрытый тестами и разработанный без учета необходимости тестирования, то уже все совсем не красиво.
Но спешу предупредить, что поднятая тема не является результатом моего эмоционального токсикоза после курса. Я начал копать потихоньку с начала года, после того, как понял, что со Снегопатом часть тестов можно будет запускать из конфигуратора :-). (Кстати, TestRunner.js для Снегопата я писал именно как прототип интерфейса).
Я стараюсь смотреть более прагматично. Я не стремлюсь к TDD, т.е. именно к разработке от тестов. Юнит-тесты - это не обязательно TDD/BDD и прочие красивые аббревиатуры. Я интересуюсь узкой задачей: написание тестов для возможности проверки кода 1С:Предприятия 8 на регрессии после изменений. Причем, уже для готового кода, более-менее приспособленного к автоматическому тестированию, т.к. основная масса его функционала изменяет что-то в одной большой таблице значений.
Я вообще с большим скепсисом отношусь к желанию тестировать все и вся, которое озвучил Женя и которое ко мне тоже приходит. Да, было бы здорово иметь возможность после внесения любого изменения узнать, не сломалось ли чего. Но к сожалению, этот идеал, как и многие другие, не достижим.
Поэтому я хочу довольствоваться малой кровью: иметь возможность писать тесты в тех случаях, когда это целесообразно с точки зрения КПД (с точки зрения отношения степени покрытия тестами часто меняющихся критичных участков кода к усилию на написание тестов и их последующую поддержку).
(5) Жень, могу показать как-нибудь вечерком, после 17.00 по Москве
через TeamViewer.
Мой скайп ты знаешь.
через TeamViewer.
Мой скайп ты знаешь.
Саш, имхо это очень сложная тема. И в первую очередь тем, что надо суметь унутре себя перестроить мышление на "сначала тест, потом код". Я вот даже начать не могу этим пользоваться. Пробовал изучать по разным книжкам, но там в-основном получается , причем обычно получается второй рисунок из той ветки. То есть на примерах "2+2" все понятно, но как это приспособить к своему реальному проекту - непонятно.
Саш, понятно, что все покрыть никогда не получится, поэтому я и уточнил что ты подразумеваешь под фразой "Какого рода места/какой программный код чаще всего "хочется" потестировать". Как вообще можно разграничить код основного функционала?
Конечно, первым делом нужно покрывать самые важные места или те места, от которых зависят важные, но которые очень сложно/муторно создавать каждый раз руками.
Конечно, первым делом нужно покрывать самые важные места или те места, от которых зависят важные, но которые очень сложно/муторно создавать каждый раз руками.
(8) Я неудачно сформулировал вопрос. Отвечу на свой вопрос сам, может быть так проясню, какого толка ответ я ожидаю.
Мне обычно "хочется" тестировать код, который
а) делает что-то, что трудно проверить "одним взглядом", например, потому что он проводит много простых вычислений над относительно большим объемом данных (результат - большая ТЗ с кучей колонок) - рутина вызвана большим объемом данных, сами расчеты проверять просто; либо второй вариант - расчет сложен с точки зрения алгоритма и необходимо проверить максимум входов/выходов, которые сами по себе подготовить не сложно, но рутинным становится процесс "скормить входные данные - сравнить выход с ожиданием";
б) потенциально часто меняется; или требования не устоялись;
в) ошибка дорогая (например, когда наличие ошибки или несвоевременное ее обнаружение выльется в неправильное принятие решения пользователем, или простои в работе предприятия и т.п.)
Если есть а), но нет б), то отсутствие тестов не критично и скорее всего будет дорого. А вот если а) и б) вместе, то это гарантированный случай, когда я "хочу" этот код протестировать.
Что касается тестирования интерфейса, то его тестировать я, в моей терминологии, чаще "не хочу", потому что ошибки в интерфейсе проверять проще и быстрее (за исключением особых случаев навороченных интерфейсов - но это скорее проблема интерфейса).
Еще одна большая для меня проблема с тестированием интерфейса:
1) требования к интерфейсу заказчики в лучшем случае формулируют на уровне "табличка с такими-то колонками", пользователю достаточно часто точности именно на таком уровне;
2) инструмент для тестирования интерфейса наоборот требует точности: точного названия у кнопки, точного порядка расположения колонок в табличном поле и т.п.
в итоге написать тесты для интерфейса-то можно (1С:Сценарное тестирование это и делает), но ломаются такие тесты очень просто, например, незначительным с точки зрения пользователей изменением в порядке обхода элементов управления.
Поэтому пока на тестирование интерфейса я вообще не только не замахиваюсь, даже в долгосрочных планах не вижу. Тут пока, имхо, тестировать руками эффективнее (кроме, возможно, каких-то частных случаев, с которыми я не сталкивался).
Мне обычно "хочется" тестировать код, который
а) делает что-то, что трудно проверить "одним взглядом", например, потому что он проводит много простых вычислений над относительно большим объемом данных (результат - большая ТЗ с кучей колонок) - рутина вызвана большим объемом данных, сами расчеты проверять просто; либо второй вариант - расчет сложен с точки зрения алгоритма и необходимо проверить максимум входов/выходов, которые сами по себе подготовить не сложно, но рутинным становится процесс "скормить входные данные - сравнить выход с ожиданием";
б) потенциально часто меняется; или требования не устоялись;
в) ошибка дорогая (например, когда наличие ошибки или несвоевременное ее обнаружение выльется в неправильное принятие решения пользователем, или простои в работе предприятия и т.п.)
Если есть а), но нет б), то отсутствие тестов не критично и скорее всего будет дорого. А вот если а) и б) вместе, то это гарантированный случай, когда я "хочу" этот код протестировать.
Что касается тестирования интерфейса, то его тестировать я, в моей терминологии, чаще "не хочу", потому что ошибки в интерфейсе проверять проще и быстрее (за исключением особых случаев навороченных интерфейсов - но это скорее проблема интерфейса).
Еще одна большая для меня проблема с тестированием интерфейса:
1) требования к интерфейсу заказчики в лучшем случае формулируют на уровне "табличка с такими-то колонками", пользователю достаточно часто точности именно на таком уровне;
2) инструмент для тестирования интерфейса наоборот требует точности: точного названия у кнопки, точного порядка расположения колонок в табличном поле и т.п.
в итоге написать тесты для интерфейса-то можно (1С:Сценарное тестирование это и делает), но ломаются такие тесты очень просто, например, незначительным с точки зрения пользователей изменением в порядке обхода элементов управления.
Поэтому пока на тестирование интерфейса я вообще не только не замахиваюсь, даже в долгосрочных планах не вижу. Тут пока, имхо, тестировать руками эффективнее (кроме, возможно, каких-то частных случаев, с которыми я не сталкивался).
(15) Ничего сложного в подготовке конфы нет.
Для SnowTest нужно добавить один общий модуль и можно тестировать.
В принципе, chessman c моей небольшой поддержкой сделал Информатор, с его помощью уже можно отказаться от общего модуля, и получить возможность юзать SnowTest без доработки/исправления конфигурации. Это пока не сделано, только в планах.
Почти полностью аналогично, как я уже делал для конфы юнит-тестирования 1С++ для 77.
Я планирую в будущем, если (0) не придумает/не сделает что-то новое и как всегда могучее, доработать SnowTest для использования без изменения конфигурации.
Для SnowTest нужно добавить один общий модуль и можно тестировать.
В принципе, chessman c моей небольшой поддержкой сделал Информатор, с его помощью уже можно отказаться от общего модуля, и получить возможность юзать SnowTest без доработки/исправления конфигурации. Это пока не сделано, только в планах.
Почти полностью аналогично, как я уже делал для конфы юнит-тестирования 1С++ для 77.
Я планирую в будущем, если (0) не придумает/не сделает что-то новое и как всегда могучее, доработать SnowTest для использования без изменения конфигурации.
(9) Запросы - это отдельная песня. Но тут не столько алгоритмическая сложность, сколько сложность с подготовкой данных для тестирования.
Вообще с одной стороны, все достаточно просто. Обычный сценарий тестирования запросов вручную:
1. заполняешь данными таблицы-источники запроса
2. вычисляешь вручную ожидание
3. выполняешь запрос и сверяешь с ожиданием
1-3 можно повторять не только для всего запроса (всего пакета запросов), а для каждого вложенного подзапроса / запроса в пакете.
И если есть данные для таблиц источника и рассчитанное ожидания, то автоматизируется это довольно легко.
Как видно, рутина возникает именно в подготовке входных данных.
Само-по себе тестирование от необходимости подготавливать данные для тестов не избавит. Но зато облегчит выполнение п. 3.
Мне сценарий видится таким:
1. подготавливаем тестовые данные и сериализуем их (либо xml либо в виде "фабрик" - кода на 1С:Предприятие 8, который создает нужные данные);
2. выполняем тестируемый запрос, проверяя вручную выход, вычисляя результат вручную;
3. после того, как убедились, что результат запроса корректен, сериализуем ожидание (например, в виде ТЗ), чтобы при следующем изменении в тексте запроса можно было сравнить результат с уже подготовленным результатом автоматически прогнав тест (не сравнивая с ожиданием вручную);
Вообще с одной стороны, все достаточно просто. Обычный сценарий тестирования запросов вручную:
1. заполняешь данными таблицы-источники запроса
2. вычисляешь вручную ожидание
3. выполняешь запрос и сверяешь с ожиданием
1-3 можно повторять не только для всего запроса (всего пакета запросов), а для каждого вложенного подзапроса / запроса в пакете.
И если есть данные для таблиц источника и рассчитанное ожидания, то автоматизируется это довольно легко.
Как видно, рутина возникает именно в подготовке входных данных.
Само-по себе тестирование от необходимости подготавливать данные для тестов не избавит. Но зато облегчит выполнение п. 3.
Мне сценарий видится таким:
1. подготавливаем тестовые данные и сериализуем их (либо xml либо в виде "фабрик" - кода на 1С:Предприятие 8, который создает нужные данные);
2. выполняем тестируемый запрос, проверяя вручную выход, вычисляя результат вручную;
3. после того, как убедились, что результат запроса корректен, сериализуем ожидание (например, в виде ТЗ), чтобы при следующем изменении в тексте запроса можно было сравнить результат с уже подготовленным результатом автоматически прогнав тест (не сравнивая с ожиданием вручную);
Лично я, как правило, работаю именно в режиме TDD, поэтому активно пользуюсь автоматизированными системами тестирования ( SnowTest и мой FuncTest.v8 [последний, конечно, сильно устарел, но свои задачи выполняет :) ] ) в течение нескольких лет.
Основных проблем несколько и они типичны для любого тестирования:
1. определить, что же в итоге нужно тестировать
2. количество тестов или величина покрытия тестами.
3. подготовка исходных данных для тестирования (это самая "больная" и трудоемкая часть тестирования)
Т.к. я работаю в режиме TDD, я не слишком заморачиваюсь с подготовкой данных.
у меня есть тестовая база с какими-то начальными данными.
Обычно я или в тесте создаю с нуля данные (через спец.фабрики объектов), или вручную подготавливаю исходные данные (просто добавляю в базу, даже без хмл-сохранения) и потом на их базе добавляю данные в тесте.
Тесты, как правило, выполняю в транзакции, поэтому нет проблем с независимостью тестов.
SnowTest юзаю для разработки через TDD различных обработок, выгрузок и т.п.
Свой FuncTest.v8 юзаю
1. для проверки или разработки отчетов, табличных документов, печатных форм.
2. для проверки запросов, состояния данных в рабочих базах - типа не изменилось ли чего-то в закрытых периодах.
Основных проблем несколько и они типичны для любого тестирования:
1. определить, что же в итоге нужно тестировать
2. количество тестов или величина покрытия тестами.
3. подготовка исходных данных для тестирования (это самая "больная" и трудоемкая часть тестирования)
Т.к. я работаю в режиме TDD, я не слишком заморачиваюсь с подготовкой данных.
у меня есть тестовая база с какими-то начальными данными.
Обычно я или в тесте создаю с нуля данные (через спец.фабрики объектов), или вручную подготавливаю исходные данные (просто добавляю в базу, даже без хмл-сохранения) и потом на их базе добавляю данные в тесте.
Тесты, как правило, выполняю в транзакции, поэтому нет проблем с независимостью тестов.
SnowTest юзаю для разработки через TDD различных обработок, выгрузок и т.п.
Свой FuncTest.v8 юзаю
1. для проверки или разработки отчетов, табличных документов, печатных форм.
2. для проверки запросов, состояния данных в рабочих базах - типа не изменилось ли чего-то в закрытых периодах.
Кстати, еще забыл по использованию своего FuncTest.v8 :
я при переносе или обмене данными в разных конфах в первую очередь юзаю тесты/запросы
я при переносе или обмене данными в разных конфах в первую очередь юзаю тесты/запросы
- запрос по количеству элементов в справочниках/регистрах
- запрос по количеству дублей и самим дублям элементов в справочниках/регистрах
(0) 1. Пока, кроме меня, мои помощники никак не могут начать тестирование, у них нет понимания полезности, а у меня все время не хватает времени на детальные пояснения
2. Сильно не хватает именно удобной системы предварительной подготовки данных для тестирования и использования этих данных для тестирования.
Штатное хмл-сохранение совсем неудобно (после смены метаданных помирает!).
Нужно что-то автоматическое, типа системы из Конвертации данных.
Самому времени не хватает написать подобное :(
Или можно тупо - собираем/разбираем данные в хмл-файл по типам, данным и именам реквизитов.
Возможно, что это будет удобно и не так сложно в написании, как кажется.
3. Видел системы тестирования:
А вообще я готов поучаствовать как в создании системы тестирования, так и в ее тестировании/использовании.
ЗЫ также у меня в моих публикациях есть примеры/ссылки на системы тестирования для 1С
Полезные ссылки (ссылки начала 2010 г)
1. Помощник тестирования функционала для "1С" 8.1
сайт автора
Интересно, но мне не нравится.
.
2. Тестирование конфигурации на открытие форм объектов (Все объекты, которые имеют формы)
не доработано - например, если у пользователя нет прав на открытие этой формы, все равно пытается ее открыть и ошибка выполнения и т.д.
.
3. Юнит-тестирование + Сравнивает универсальные коллекции (разбирая рекрсивно где нужно), документы, справочники.
Очень неплохо.
.
4.
Тот же автор, что и 3 (только под другим ником)
Чистые юнит-тесты,
не все хорошо и красиво, но работает.
.
5. FuncTest.v8
пока слабовато - хотя зачаток юнит-тестов есть
.
6. Моя Система тестирования функциональных тестов FuncTest_Для_1cv8
Много хорошего - построена на ООП, четко расписан интерфейс обработчиков, несложно добавлять новые классы-расчетчики ожиданий, куча уже готовых удобных и проверенных расчетчиков-ожиданий, быстро работает,
но к ней также есть претензии - юнит-тесты практически совсем неудобно писать, форма браузера тяжеловата и не очень удобна.
но функциональные тесты вполне способна выполнять и выполняет.
2. Сильно не хватает именно удобной системы предварительной подготовки данных для тестирования и использования этих данных для тестирования.
Штатное хмл-сохранение совсем неудобно (после смены метаданных помирает!).
Нужно что-то автоматическое, типа системы из Конвертации данных.
Самому времени не хватает написать подобное :(
Или можно тупо - собираем/разбираем данные в хмл-файл по типам, данным и именам реквизитов.
Возможно, что это будет удобно и не так сложно в написании, как кажется.
3. Видел системы тестирования:
- Сценарное тестирование. ИМХО ужас, как-то совсем нежизнеспособно. Тестирование интерфейса нужно очень/очень редко.
- SnowTest - как база для TDD очень хорошо. Потихоньку его корректирую для более удобного тестирования.
- мой Functest.v8 - для TDD отчетов, печатных форм, запрос неплох. Интерфейс,конечно, сильно устаревший.
- На систему Палыча давно облизываюсь, но только по отзывам.
- Бизнес-плюс: Выполнение правил проверки - не видел. Нужно поискать, почитать.
А вообще я готов поучаствовать как в создании системы тестирования, так и в ее тестировании/использовании.
ЗЫ также у меня в моих публикациях есть примеры/ссылки на системы тестирования для 1С
Полезные ссылки (ссылки начала 2010 г)
1. Помощник тестирования функционала для "1С" 8.1
сайт автора
Интересно, но мне не нравится.
.
2. Тестирование конфигурации на открытие форм объектов (Все объекты, которые имеют формы)
не доработано - например, если у пользователя нет прав на открытие этой формы, все равно пытается ее открыть и ошибка выполнения и т.д.
.
3. Юнит-тестирование + Сравнивает универсальные коллекции (разбирая рекрсивно где нужно), документы, справочники.
Очень неплохо.
.
4.
Тот же автор, что и 3 (только под другим ником)
Чистые юнит-тесты,
не все хорошо и красиво, но работает.
.
5. FuncTest.v8
пока слабовато - хотя зачаток юнит-тестов есть
.
6. Моя Система тестирования функциональных тестов FuncTest_Для_1cv8
Много хорошего - построена на ООП, четко расписан интерфейс обработчиков, несложно добавлять новые классы-расчетчики ожиданий, куча уже готовых удобных и проверенных расчетчиков-ожиданий, быстро работает,
но к ней также есть претензии - юнит-тесты практически совсем неудобно писать, форма браузера тяжеловата и не очень удобна.
но функциональные тесты вполне способна выполнять и выполняет.
(16) Артур, спасибо за комментарии! Надеялся на твое участие :)
Спасибо за ссылки, но:
1. - публикация не активна, посмотреть не имею возможности; указанный сайт автора также не открывается.
2. - решение видел, но это скорее "автоматизированная проверка", нежели тестирование; это решение нужное, но очень узкое. У 1С есть более мощное свободное решение 1С:Автоматизированная проверка конфигураций, в ней есть такая функция, если не ошибаюсь.
3. - очень интересно посмотреть, особенно в части "сравнивает универсальные коллекции", но публикация как и в п. 1 неактивна;
4. Скачал, посмотрю, интересно, если судить с первого взгляда.
5. - публикация не активна; но что это? я думал FuncTest.v8 - это именно твое решение, но как я понимаю, твое - это FuncTest_Для_1cv8?
5. Буду разбираться пристальнее.
По поводу "Бизнес-плюса", есть подозрение, что разработку "прикрыли" или отдали кому-то еще. На демо-сервер не достучаться к ним, хотя я давно там зарегистрирован. Написал письмо им, буду ждать ответа - хочется посмотреть. Насколько я помню из описания решения, которое когда-то попадало ко мне (когда не нужно было :-(), решение может работать как 1С:Автоматизированной проверка, с возможностью настройки своих правил, хранимых в xml-файлах, и в том числе выполнять произвольный проверочный код, являющийся аналогом юнит-тестов.
По поводу 1С:Сценарного тестирования: смотрел разработку вживую, опять года три назад, когда мне было еще не до того. Отметил для себя основательный подход: очень подробная документация с методикой использования. Ни одно решение по этому пункту конкурировать не может. Еще из плюсов: наличие тестов под типовые, публикуемые на users.v8.1c.ru (которые, впрочем, уже почти полностью потеряли актуальность).
Из минусов - подход от "интерфейса", в этом я тебя поддержу - проект провальный. Как я писал выше, такие тесты "долго не живут". Есть подозрение, в 1С также перестали пользоваться из-за больших сложностей поддержания тестов. Интересно, чем группа разработки БП под руководством Олега Фогеля тестирует теперь БП. Он (Фогель), судя по его выступлениям, сторонник гибких методик.
И, важно отметить, ни одно из существующих решений не поддерживают тестирование на клиенте для управляемых форм.
Спасибо за ссылки, но:
1. - публикация не активна, посмотреть не имею возможности; указанный сайт автора также не открывается.
2. - решение видел, но это скорее "автоматизированная проверка", нежели тестирование; это решение нужное, но очень узкое. У 1С есть более мощное свободное решение 1С:Автоматизированная проверка конфигураций, в ней есть такая функция, если не ошибаюсь.
3. - очень интересно посмотреть, особенно в части "сравнивает универсальные коллекции", но публикация как и в п. 1 неактивна;
4. Скачал, посмотрю, интересно, если судить с первого взгляда.
5. - публикация не активна; но что это? я думал FuncTest.v8 - это именно твое решение, но как я понимаю, твое - это FuncTest_Для_1cv8?
5. Буду разбираться пристальнее.
По поводу "Бизнес-плюса", есть подозрение, что разработку "прикрыли" или отдали кому-то еще. На демо-сервер не достучаться к ним, хотя я давно там зарегистрирован. Написал письмо им, буду ждать ответа - хочется посмотреть. Насколько я помню из описания решения, которое когда-то попадало ко мне (когда не нужно было :-(), решение может работать как 1С:Автоматизированной проверка, с возможностью настройки своих правил, хранимых в xml-файлах, и в том числе выполнять произвольный проверочный код, являющийся аналогом юнит-тестов.
По поводу 1С:Сценарного тестирования: смотрел разработку вживую, опять года три назад, когда мне было еще не до того. Отметил для себя основательный подход: очень подробная документация с методикой использования. Ни одно решение по этому пункту конкурировать не может. Еще из плюсов: наличие тестов под типовые, публикуемые на users.v8.1c.ru (которые, впрочем, уже почти полностью потеряли актуальность).
Из минусов - подход от "интерфейса", в этом я тебя поддержу - проект провальный. Как я писал выше, такие тесты "долго не живут". Есть подозрение, в 1С также перестали пользоваться из-за больших сложностей поддержания тестов. Интересно, чем группа разработки БП под руководством Олега Фогеля тестирует теперь БП. Он (Фогель), судя по его выступлениям, сторонник гибких методик.
И, важно отметить, ни одно из существующих решений не поддерживают тестирование на клиенте для управляемых форм.
(25) artbear, Так и не встроил в мою обработку ничего, хотя сравнение с эталоном я добавил.
(0) Пользуюсь своей разработкой . Почему?
В 2010 провел исследования по системам тестирования для 1С. Сравнивался функционал (что смог найти):
1. TestComplete
2. Сценарное тестирование
Первое, классный продукт, но вся его мощь заканчивается на первом же прогоне теста. Связано с особыми классами окон у 1С. Месячная активная переписка с разработчиками (тех поддержка у программы на 5+) ни к чему не привела.
Второе, все хорошо пока не пишешь с нуля. То есть когда есть с чем сравнивать. Если сравнивать не с чем, то написание тест-кейсов превращается в танцы с бубном.
P.S. А так работа тестировщика - это 90% ручного труда + усидчивость.
(0) Пользуюсь своей разработкой . Почему?
В 2010 провел исследования по системам тестирования для 1С. Сравнивался функционал (что смог найти):
1. TestComplete
2. Сценарное тестирование
Первое, классный продукт, но вся его мощь заканчивается на первом же прогоне теста. Связано с особыми классами окон у 1С. Месячная активная переписка с разработчиками (тех поддержка у программы на 5+) ни к чему не привела.
Второе, все хорошо пока не пишешь с нуля. То есть когда есть с чем сравнивать. Если сравнивать не с чем, то написание тест-кейсов превращается в танцы с бубном.
P.S. А так работа тестировщика - это 90% ручного труда + усидчивость.
(28) Спасибо! Познакомлюсь с вашей обработкой. По результатам сравнения функционала не было статьи, случаем? Было бы интересно познакомиться с вашим анализом.
Пожалуйста, как практикующий тестирование специалист, ответьте на мои вопросы 1 и 2 из поста (1).
По поводу Сценарного тестирования не очень ясна мысль "Второе, все хорошо пока не пишешь с нуля. То есть когда есть с чем сравнивать. Если сравнивать не с чем, то написание тест-кейсов превращается в танцы с бубном."
Правильно ли я понял, что сложность в отсутствии эталона, в необходимости его подготовки? Но если это так, то вряд ли какая-то система может сама подобрать данные для входа и правильные ожидания (выходы), это независимо от инструмента необходимо готовить вручную, человеку.
Пожалуйста, как практикующий тестирование специалист, ответьте на мои вопросы 1 и 2 из поста (1).
По поводу Сценарного тестирования не очень ясна мысль "Второе, все хорошо пока не пишешь с нуля. То есть когда есть с чем сравнивать. Если сравнивать не с чем, то написание тест-кейсов превращается в танцы с бубном."
Правильно ли я понял, что сложность в отсутствии эталона, в необходимости его подготовки? Но если это так, то вряд ли какая-то система может сама подобрать данные для входа и правильные ожидания (выходы), это независимо от инструмента необходимо готовить вручную, человеку.
(29) kuntashov,
1. Команда я один(второго программиста 7-ой месяц жду, вопрос не в деньгах). Проект на Android(Java) - 1C 8 - SQL - 1C 7(два программиста и не я, слава богу). Так что тестирование - написал, проверил. Или переводя на русский тестировщиками выступают пользователи. Потыкали по кнопкам - написали в редмайне задачу, исправил - проверели. Это не тестирование - это поддержание штанов. Разделаюсь с первым этапом, займусь переделкой своей обработки, там хлама много, да и управляемые формы не поддерживаются.
2. Хочется совместить приятное с полезным, а именно написание требований к системе с созданием тест-кейсов. Написал требование - тест-кейс(ы). И конечно запись тестов как в TestComplete. Посчелкал мышкой, постучал по клаве - вот тебе и сценарий, ну и желательно на встроенном языке от 1С.
Да понял правильно. Но вывод:
неправильные. Критерием успеха/провала теста не обязательно должны быть правильные/не правильные данные на выходе. Критерием может быть и выполнение/не выполнение функции. То есть если объект А с параметрами Б должен приводить к ошибке записи, а не приводит, то это и есть ошибка. Таким образом надо сделать только входные данные.
(30) artbear, С доработками подожди, я ее причесывать буду на следующей неделе. Там code-hell в модулях.
(31) TDD - это очень хорошо. Но я не сторонник совмещения ролей тестировщик/программист. То что вы называете тестированием - я называю проверкой(тут готовые, автоматизированные тесты как нельзя к месту). Тестировать должен специально обученный человек. И начинать он должен с тестирования ТЗ (один раз реализовал много багов до написания первой строчки кода выловили). Но это мое ИМХО.
1. Команда я один(второго программиста 7-ой месяц жду, вопрос не в деньгах). Проект на Android(Java) - 1C 8 - SQL - 1C 7(два программиста и не я, слава богу). Так что тестирование - написал, проверил. Или переводя на русский тестировщиками выступают пользователи. Потыкали по кнопкам - написали в редмайне задачу, исправил - проверели. Это не тестирование - это поддержание штанов. Разделаюсь с первым этапом, займусь переделкой своей обработки, там хлама много, да и управляемые формы не поддерживаются.
2. Хочется совместить приятное с полезным, а именно написание требований к системе с созданием тест-кейсов. Написал требование - тест-кейс(ы). И конечно запись тестов как в TestComplete. Посчелкал мышкой, постучал по клаве - вот тебе и сценарий, ну и желательно на встроенном языке от 1С.
Правильно ли я понял, что сложность в отсутствии эталона, в необходимости его подготовки? Но если это так, то вряд ли какая-то система может сама подобрать данные для входа и правильные ожидания (выходы), это независимо от инструмента необходимо готовить вручную, человеку.
Да понял правильно. Но вывод:
вряд ли какая-то система может сама подобрать данные для входа и правильные ожидания (выходы)
неправильные. Критерием успеха/провала теста не обязательно должны быть правильные/не правильные данные на выходе. Критерием может быть и выполнение/не выполнение функции. То есть если объект А с параметрами Б должен приводить к ошибке записи, а не приводит, то это и есть ошибка. Таким образом надо сделать только входные данные.
(30) artbear, С доработками подожди, я ее причесывать буду на следующей неделе. Там code-hell в модулях.
(31) TDD - это очень хорошо. Но я не сторонник совмещения ролей тестировщик/программист. То что вы называете тестированием - я называю проверкой(тут готовые, автоматизированные тесты как нельзя к месту). Тестировать должен специально обученный человек. И начинать он должен с тестирования ТЗ (один раз реализовал много багов до написания первой строчки кода выловили). Но это мое ИМХО.
(33)
> Критерием успеха/провала теста не обязательно должны быть правильные/не правильные данные на выходе. Критерием может быть и выполнение/не выполнение функции.
Ваша позиция понятна.
"Выход" я понимаю в общем смысле - как ожидаемое поведение вообще. Выполнение/Не выполнение - это частный случай ожидания. Т.е. ожидаемым поведением может быть как корректно возвращенное функцией значение, так и брошенное исключение. Понимаю, что это вопрос подхода, терминологии.
Я обозначил проблему: не имея аналогичного по функционалу КОРРЕКТНО работающего кода по заданному входу автоматически не получить корректный с точки зрения требований выход для проверки тестируемого кода. Даже если ожидание (выход) состоит в ожидании конкретного исключения (а не исключения вообще). Т.е. этап ручной подготовки эталонных данных и ожиданий будет присутствовать всегда. Исключение составляют отдельные частные случаи, которые можно либо полностью либо частично автоматизировать.
> Критерием успеха/провала теста не обязательно должны быть правильные/не правильные данные на выходе. Критерием может быть и выполнение/не выполнение функции.
Ваша позиция понятна.
"Выход" я понимаю в общем смысле - как ожидаемое поведение вообще. Выполнение/Не выполнение - это частный случай ожидания. Т.е. ожидаемым поведением может быть как корректно возвращенное функцией значение, так и брошенное исключение. Понимаю, что это вопрос подхода, терминологии.
Я обозначил проблему: не имея аналогичного по функционалу КОРРЕКТНО работающего кода по заданному входу автоматически не получить корректный с точки зрения требований выход для проверки тестируемого кода. Даже если ожидание (выход) состоит в ожидании конкретного исключения (а не исключения вообще). Т.е. этап ручной подготовки эталонных данных и ожиданий будет присутствовать всегда. Исключение составляют отдельные частные случаи, которые можно либо полностью либо частично автоматизировать.
(34) kuntashov, Пара идей которые можно реализовать:
1. В 1С есть замер производительности. Была мысль через него организовать отчет о покрытии кода тестами, но руки не дошли (без снегопада тяжко было).
2. При открытии формы можно сделать ее скриншет. И пропустив через фильтры сравнить с эталонной картинкой которая должна совпать на n% (идея сперта у Microsoft).
3. Автоматическое внедрение кода в формы типа:
Процедура _Выполнить(Метод, ПараметрыМетода) Экспорт
Выполнить(Метод);
КонецПроцедуры
Для эмуляции щелчков по контролам.
1. В 1С есть замер производительности. Была мысль через него организовать отчет о покрытии кода тестами, но руки не дошли (без снегопада тяжко было).
2. При открытии формы можно сделать ее скриншет. И пропустив через фильтры сравнить с эталонной картинкой которая должна совпать на n% (идея сперта у Microsoft).
3. Автоматическое внедрение кода в формы типа:
Процедура _Выполнить(Метод, ПараметрыМетода) Экспорт
Выполнить(Метод);
КонецПроцедуры
Для эмуляции щелчков по контролам.
(28) Да, времени не хватило, а потом как-то забылось.
Я думал, что ты сравнение с образцом так и не встроил :(
Мне в твоей обработке нравится интерфейс и возможность развития.
Подумаю над своими возможными доработками в твою систему.
Возможно, что Саше (ТС) нужно присмотреться именно к твоей разработке как к базовой.
Я думал, что ты сравнение с образцом так и не встроил :(
Мне в твоей обработке нравится интерфейс и возможность развития.
Подумаю над своими возможными доработками в твою систему.
Возможно, что Саше (ТС) нужно присмотреться именно к твоей разработке как к базовой.
(28) >>А так работа тестировщика - это 90% ручного труда + усидчивость.
Я бы так не сказал, все зависит от организации труда тестировщика.
Я, как разработчик, считаю наиболее востребованной систему типа TDD - получаем максимальную отдачу при не слишком сильных затратах на построение тестов.
При этом сразу происходит проектирование общей схемы работы/интерфейса работы + наполнение тестами идет постепенно, не нагружая разработчика сразу одновременно большим количеством кода и одновременно большим количеством тестов.
Я бы так не сказал, все зависит от организации труда тестировщика.
Я, как разработчик, считаю наиболее востребованной систему типа TDD - получаем максимальную отдачу при не слишком сильных затратах на построение тестов.
При этом сразу происходит проектирование общей схемы работы/интерфейса работы + наполнение тестами идет постепенно, не нагружая разработчика сразу одновременно большим количеством кода и одновременно большим количеством тестов.
(31) Судя по всему у нас с тобой понимание сходится. Я тоже, чем больше погружаюсь, тем больше понимаю, что максимально эффективным тестирование разработчиком может выполняться на уровне юнит-тестирования. Все остальные виды тестирования становятся "дорогими" по усилиям, что польза от таких тестов сводится к "0".
(0) ОФФ. Прикольно, гугл уже проиндексировал ИС и поиск по Б+: Выполнение правил проверки дает нашу ветку на первой же странице :)
Тестами не пользуюсь... Понимаю, что надо - но такая дикая текучка, столько работы, что никак не соберусь взяться... Хотя может быть причина еще и в том, что нет заказчиков... Ведь внедрение тестов неминуемо повысит затраты времени на разработку, что приведет к увеличению цены. Далеко не все готовы платить за возросшее качество.
(21) Кроме вопроса "дополнительного" качества (улучшение качества новых решений по сравнению со старыми) есть большой пласт задач поддержки существующих решений, в которых надо доработать какую-то часть, не сломав остальное.
Я повторю, что в первую очередь сейчас озабочен задачей сохранения качества, а не улучшения в глобальном смысле. Т.е. пока я ограничиваюсь задачей организации регрессионного тестирования.
Я повторю, что в первую очередь сейчас озабочен задачей сохранения качества, а не улучшения в глобальном смысле. Т.е. пока я ограничиваюсь задачей организации регрессионного тестирования.
Тестирую как правило сам основу, но считаю более правильно, чтоб тестировал человек с незамыленным глазом, который не писал это. Сколько раз наблюдал ситуацию, что когда проверяет другой, находит очень быстро те ошибки, которые ты в упор не видел.
По "Бизнес-плюс:Стандарты разработки" и включенной в опрос "Бизнес-плюс:Выполнение правил проверки" документацию можно найти здесь:
Судя по предупреждению "Техподдержка по данной услуге заканчивается 31 декабря 2010 года" на странице решения ( продукт снят с поддержки и не развивается.
Судя по предупреждению "Техподдержка по данной услуге заканчивается 31 декабря 2010 года" на странице решения ( продукт снят с поддержки и не развивается.
У меня пока так
* в любую конфигурацию встраивается модуль Я_Тест от Федора - то есть SnowTest.
* использую FuncTest от Артура, но в последнее время все реже, так как основная разработка сейчас идет в режиме 8.2 и управляемых форм
* собственные модули тестирования функционала на основе идеи метода _Выполнить()
** Сценарное тестирование использовал - но оно не летит совсем
Фантазировать пока не готов - я перепробовал почти все из озвученного, и пока готов сказать что не хватает некоего стандартного набора для 1С и стандарта его использования - отсюда и возникает некоторая хаотичность в инструментах тестирования
И если уж совсем мечтать: ну вот например для юнит-тестирования существует же - хочется иметь его портированную версию для запуска напрямую в конфигураторе
Хочу mock объекты и тоже в конфигураторе ;-)
Хочу специфичные assert'ы для 1С и тоже в конфигураторе - assert_ДокументПроведен!
много чего хочу.
честно говоря на моей работе 80 разработчиков 1С и никакого стандарта не прижилось - тестирует кто во что горазд: я пытаюсь периодически пролобировать создание внутреннего стандарта и проведение внутренних тренингов по тестированию, но пока безуспешно (даже помнится писал внутренний циркуляр где описывал подходы и инструменты)
P.S. Помнится мне однажды при нашей личной встрече Федор Езеев сказал что "в принципе фрэймворк для тестирования можно написать на любом языке", согласен с ним полностью - стандарт в принципе общемировой известен по написанию таких библиотек, НО применительно к 1С мы сильно ограниченны в возможностях самой платформой - постоянно приходится выкручиваться. Интересно что он скажет сейчас - все таки прошло около 4-ех лет по моему как он в Яндексе "тестирует" ;-). Его бы опыт сюда.
P.S.S. Кстати - информация по состоянию на вчера
* внутренние механизмы для тестирования которые были анонсированы в 8.2.16 являются фичей которую 1С-ники могут включить а могут и не включить в релиз
* сама 8.2.16 появится скорее всего не раньше осени
* вполне возможно что 8.2.16 будет называться 8.3 ;-)
* и вообще скорее всего они опять сделают НЕДОинструмент, по аналогии с НЕДОхранилищемКонфигурации
поэтому на вопрос - так как же тогда тестировать, я вчера получил ответ "А может Вам лучше забить на тестирования?" - грустно ;-)
* в любую конфигурацию встраивается модуль Я_Тест от Федора - то есть SnowTest.
* использую FuncTest от Артура, но в последнее время все реже, так как основная разработка сейчас идет в режиме 8.2 и управляемых форм
* собственные модули тестирования функционала на основе идеи метода _Выполнить()
** Сценарное тестирование использовал - но оно не летит совсем
Фантазировать пока не готов - я перепробовал почти все из озвученного, и пока готов сказать что не хватает некоего стандартного набора для 1С и стандарта его использования - отсюда и возникает некоторая хаотичность в инструментах тестирования
И если уж совсем мечтать: ну вот например для юнит-тестирования существует же - хочется иметь его портированную версию для запуска напрямую в конфигураторе
Хочу mock объекты и тоже в конфигураторе ;-)
Хочу специфичные assert'ы для 1С и тоже в конфигураторе - assert_ДокументПроведен!
много чего хочу.
честно говоря на моей работе 80 разработчиков 1С и никакого стандарта не прижилось - тестирует кто во что горазд: я пытаюсь периодически пролобировать создание внутреннего стандарта и проведение внутренних тренингов по тестированию, но пока безуспешно (даже помнится писал внутренний циркуляр где описывал подходы и инструменты)
P.S. Помнится мне однажды при нашей личной встрече Федор Езеев сказал что "в принципе фрэймворк для тестирования можно написать на любом языке", согласен с ним полностью - стандарт в принципе общемировой известен по написанию таких библиотек, НО применительно к 1С мы сильно ограниченны в возможностях самой платформой - постоянно приходится выкручиваться. Интересно что он скажет сейчас - все таки прошло около 4-ех лет по моему как он в Яндексе "тестирует" ;-). Его бы опыт сюда.
P.S.S. Кстати - информация по состоянию на вчера
* внутренние механизмы для тестирования которые были анонсированы в 8.2.16 являются фичей которую 1С-ники могут включить а могут и не включить в релиз
* сама 8.2.16 появится скорее всего не раньше осени
* вполне возможно что 8.2.16 будет называться 8.3 ;-)
* и вообще скорее всего они опять сделают НЕДОинструмент, по аналогии с НЕДОхранилищемКонфигурации
поэтому на вопрос - так как же тогда тестировать, я вчера получил ответ "А может Вам лучше забить на тестирования?" - грустно ;-)
(37), (38) Спасибо за комментарии!
Каких "специфичных" assert'ов (Проверить* в терминах SnowTest) не хватает? Насчет mock-объектов я думаю. В принципе, для собственных методов (не встроенных в платформу), многие типовые прикладные объекты (ИнтернетПочта и т.п.) можно "замОкить" (от mock :-)) при помощи обработок. Жаль, что встроенные в платформу методы не поддерживают duck typing.
По поводу 8.2.16 - честно говоря, сложно надеяться. Когда появится, тогда и будем думать, как это можно использовать будет.
p.s.
<Режим интриги>Запуск тестов из конфигуратора возможен, прототип на базе SnowTest'а у меня уже есть :-)</Режим интриги>
Каких "специфичных" assert'ов (Проверить* в терминах SnowTest) не хватает? Насчет mock-объектов я думаю. В принципе, для собственных методов (не встроенных в платформу), многие типовые прикладные объекты (ИнтернетПочта и т.п.) можно "замОкить" (от mock :-)) при помощи обработок. Жаль, что встроенные в платформу методы не поддерживают duck typing.
По поводу 8.2.16 - честно говоря, сложно надеяться. Когда появится, тогда и будем думать, как это можно использовать будет.
p.s.
<Режим интриги>Запуск тестов из конфигуратора возможен, прототип на базе SnowTest'а у меня уже есть :-)</Режим интриги>
да кстати собственные модули тестирования - это модули по типу:
соотвественно после прогона всех потоков товара в моем случае - есть некоторое состояние ИБ, отсутствие ошибок в ЖР, отчеты показывают ожидаемые остатки и т.д. - это уже проверяется визуально по check-list'у.
Таким образом у меня покрыты все товарные потоки "как бы тестами" ;-). Другого пока не придумал.
Процедуры Тест_ПотокТовараМобильник()
мобильник = СоздатьМобильник();
грузовыеМеста = ПринятьПаллетыСМобильникомПоГрузовымМестам(мобильник, 10);
РазместитьГрузовыеМестаВЗонуВременногоХранения(грузовыеМеста);
...
КонецПроцедуры
соотвественно после прогона всех потоков товара в моем случае - есть некоторое состояние ИБ, отсутствие ошибок в ЖР, отчеты показывают ожидаемые остатки и т.д. - это уже проверяется визуально по check-list'у.
Таким образом у меня покрыты все товарные потоки "как бы тестами" ;-). Другого пока не придумал.
[Заинтригован]Такое возможно чувствую только со Снегопатом - но в репозитарии прототипа пока нету ?[/Заинтригован]
про 8.2.16 - это я так чтобы в курсе были последних новостей
"Специфичными ассертами" - тут я наверное не так выразился:
я бы хотел не только "заглушки" (mock), но и возможность создания "фиктивных объектов" (stub)
и еще - хочется генератор заготовок тестов, по шаблонам.
про 8.2.16 - это я так чтобы в курсе были последних новостей
"Специфичными ассертами" - тут я наверное не так выразился:
я бы хотел не только "заглушки" (mock), но и возможность создания "фиктивных объектов" (stub)
и еще - хочется генератор заготовок тестов, по шаблонам.
(40) Да, только со Снегопатом. В репозиторий не заливал, потому что пока играюсь и не готов публично показывать, но в ближайшее время причешу и предоставлю на обозрение общественности.
По терминологии, кажется, наоборот, stub - заглушка (перехватывает какой-нибудь метод и за него возвращает фиктивный результат), mock - "подставной" объект, действующий по такому же принципу, но не суть, я все понял.
Насчет генератора - да, эта фича у меня записана. Но тут кроме технической стороны нужна наработка методик/подходов к тестированию определенных ситуаций (кейсов). Надо с Артуром договориться и попытать его всем вместе, чтобы он нам рассказал, как это делает он, у него потому что, имхо, самый большой накопленный опыт автоматизированного тестирования на 1С:Предприятии 8. Он тут выше персонально JohnyDeath'у удаленную демонстрацию обещал, может быть раскрутить его на небольшой вебинар для заинтересованного круга лиц? :)
По терминологии, кажется, наоборот, stub - заглушка (перехватывает какой-нибудь метод и за него возвращает фиктивный результат), mock - "подставной" объект, действующий по такому же принципу, но не суть, я все понял.
Насчет генератора - да, эта фича у меня записана. Но тут кроме технической стороны нужна наработка методик/подходов к тестированию определенных ситуаций (кейсов). Надо с Артуром договориться и попытать его всем вместе, чтобы он нам рассказал, как это делает он, у него потому что, имхо, самый большой накопленный опыт автоматизированного тестирования на 1С:Предприятии 8. Он тут выше персонально JohnyDeath'у удаленную демонстрацию обещал, может быть раскрутить его на небольшой вебинар для заинтересованного круга лиц? :)
[Интрига 2]Между прочим, chessman сделал реализацию ООП для 8-ки - я чуть-чуть поучаствовал в тестировании.
Даже можно объекты создавать нативно: Объект = Новый Информатор; :)[/Интрига 2]
ИМХО для целей тестирования также сгодится, но пока у меня лично времени не хватает на анализ и тестирование его работы :(
Даже можно объекты создавать нативно: Объект = Новый Информатор; :)[/Интрига 2]
ИМХО для целей тестирования также сгодится, но пока у меня лично времени не хватает на анализ и тестирование его работы :(
(45) Я уже в тестировании применяю СписокОкон от этого же автора, и планирую Информатор.v8 применять также, как применил свой Информатор.v7 при разработке конфигурации тестирования 1С++.
Тогда очень красиво получилось - тесты подхватывались на лету, разработка в режиме TDD была ну очень быстрая :)
смогли довольно быстро повысить стабильность 1С++.
Для SnowTest или его аналогов можно сделать почти аналогично.
ЗЫ но пока проблема со временем.
Тогда очень красиво получилось - тесты подхватывались на лету, разработка в режиме TDD была ну очень быстрая :)
смогли довольно быстро повысить стабильность 1С++.
Для SnowTest или его аналогов можно сделать почти аналогично.
ЗЫ но пока проблема со временем.
Я пока не придумал, как применить mock-и\stub-ы для тестирования в 1С.
может быть, не очень четко представляю, как их юзать.
можете посоветовать какую-нибудь достойную книгу/статью по этим объектам (лучше на русском для упрощения понимания)
может быть, не очень четко представляю, как их юзать.
можете посоветовать какую-нибудь достойную книгу/статью по этим объектам (лучше на русском для упрощения понимания)
artbear,
>кроме меня, мои помощники никак не могут начать тестирование, у них нет понимания полезности, а у меня все время не хватает времени на детальные пояснения
Да всё мы прекрасно понимаем, полезность осознаем, уже даже несколько раз пробовали, особенно пригодилось при написании функции для расчета стажа работников наших магазинов) С десяток разных хитрых условий, и нужно, чтобы ничего не полетело после внесенных изменений. Да, в тот день тесты серьезно упростили мне работу. К тому же, я Вам лично уже рассказывал, как страдал без тестов, потому что просто не знал о существовании такой концепции, когда писал диплом в учебном заведении.
Видел только SnowTest и FuncTest Артура, особой разницы в использовании не заметил, видимо просто потому, что мало пользовался. Не начинаю работать по принципу TDD просто потому, что недостаточно понимаю ее суть. Но какие наши годы)
>кроме меня, мои помощники никак не могут начать тестирование, у них нет понимания полезности, а у меня все время не хватает времени на детальные пояснения
Да всё мы прекрасно понимаем, полезность осознаем, уже даже несколько раз пробовали, особенно пригодилось при написании функции для расчета стажа работников наших магазинов) С десяток разных хитрых условий, и нужно, чтобы ничего не полетело после внесенных изменений. Да, в тот день тесты серьезно упростили мне работу. К тому же, я Вам лично уже рассказывал, как страдал без тестов, потому что просто не знал о существовании такой концепции, когда писал диплом в учебном заведении.
Видел только SnowTest и FuncTest Артура, особой разницы в использовании не заметил, видимо просто потому, что мало пользовался. Не начинаю работать по принципу TDD просто потому, что недостаточно понимаю ее суть. Но какие наши годы)
(49) yurii_host, это я опрос делал в начале 2012 года
Потом взял несколько наработок, модуль Я_Тест из SnowTest'а, нарисовал примитивный интерфейс запускателя тестов, файл назвал TestRunner.epf
Потом была пауза где-то до ноября, потом поехал на первый Инфостарт Ивент, где встретились наконец-то впервые очно почти все участники из переписки выше.
Там я рассказал Артуру про свои эксперименты и как всегда уговорил меня прислать их ему, в итоге я сначала выслал их Артуту, а параллельно опубликовал на гитхабе как 1CUnit.
Через некоторое время его переименовали в xUnitFor1C :))))
Потом взял несколько наработок, модуль Я_Тест из SnowTest'а, нарисовал примитивный интерфейс запускателя тестов, файл назвал TestRunner.epf
Потом была пауза где-то до ноября, потом поехал на первый Инфостарт Ивент, где встретились наконец-то впервые очно почти все участники из переписки выше.
Там я рассказал Артуру про свои эксперименты и как всегда уговорил меня прислать их ему, в итоге я сначала выслал их Артуту, а параллельно опубликовал на гитхабе как 1CUnit.
Через некоторое время его переименовали в xUnitFor1C :))))
(53) artbear, (52) kuntashov, на мой взгляд, удачная идея, сделать через "браузер-фреймворк".
Программный интерфейс тоже хорошо продуман - простой и понятный. Только вот некоторые необязательные методы в попытке вызываются. Есть несущественные неудобства при отладке с остановкой по ошибке. Но это лечится легко - добавлением всех необязательных методов в тест.
Возможность задавать параметры для тестов и объединять их в группы - тоже облегчает тестирование.
А идея с плагинами в реборне - вообще огонь. Раньше приходилось свои библиотеки вызвать из внешних обработок, что неудобно, когда пишешь на разных машинах. Теперь можно их просто закинуть в папку с плагинами.
В общем очень круто получилось. Удобно и разрабатывать и искать ошибки, когда что-нибудь сломается после чьей-нибудь доработки.
Программный интерфейс тоже хорошо продуман - простой и понятный. Только вот некоторые необязательные методы в попытке вызываются. Есть несущественные неудобства при отладке с остановкой по ошибке. Но это лечится легко - добавлением всех необязательных методов в тест.
Возможность задавать параметры для тестов и объединять их в группы - тоже облегчает тестирование.
А идея с плагинами в реборне - вообще огонь. Раньше приходилось свои библиотеки вызвать из внешних обработок, что неудобно, когда пишешь на разных машинах. Теперь можно их просто закинуть в папку с плагинами.
В общем очень круто получилось. Удобно и разрабатывать и искать ошибки, когда что-нибудь сломается после чьей-нибудь доработки.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот