Задали мне такой вопрос на собеседовании - дескать, какие скрипты и средства автоматизации я использую для тестирования разработок и доработок, чем и поставили меня немного в тупик) Так как тестирую я своими руками и глазами, а затем отдаю на откуп пользователям, которые тоже тестируют, в том числе в рабочей базе. Вот вопрос - а какие средства для тестирования имеются в арсенале 1С-ников? Разработчиков типовых не касаемся.

насколько я знаю 1с делает только первые шаги в сторону автоматизированного тестирования и контор которые автоматизированное тестирование конфигураций применяют - единицы.
в других сферах автоматизация тестирования вполне обычное явление. мой товарищ как раз занимается этим - пишет тесты для своих филиппинских разработчиков. сам в Австралии, RubyOnRails они ваяют или как-то так.

Буяк-буяк - и в продакшен, как же ещё.

И зп наверное у них выше чем по рынку?А так обычно понты

Не думаю что кто то возится с авто тестированием, в 1с это дорого и не нужно (касается только типовых, если свой велосипед то наверное тестируют).

А как вообще выглядит суть этого авто-тестирования? Написать код, который будет эмитировать действия пользователей в определенной последовательности? Так если мы это запрограммировали, значит поведение ясное, его и руками можно проверить. Ошибки же вылазят, чаще, когда систему используются не так как предполагается (не та последовательно действий и т.д.)...

(5) TDD же, когда сначала тесты пишут для проверки кода а только затем сам код.
http://catalog.mista.ru/public/326820/
http://catalog.mista.ru/public/418168/
https://github.com/xDrivenDevelopment/xUnitFor1C/wiki/Статьи-и-видео-по-тестированию-в-1С

(6) В реальности эта хрень нужна когда есть один вменяемый разраб который пишет тесты и куча невменяемых 1С-кодеров.
Чтобы хоть как то за кодерами следить.

Но это все равно сильно хуже найма вменяемых 1Сников, потому что да нельзя проверить то что не предусмотрел (не догадался) вменяемый при тестах, хотя при разработке он бы об этом подумал.

(5) Смысл тестирования еще и в том, чтобы запускать тесты постоянно при каждой сборке и вся польза тестов проявляется когда условный Вася изменил модуль в который 2 года никто не лазил:
Вася с тестами: увидел что не прошли тесты - исправил ошибки(или тесты) до релиза
Вася без тестов: увидел ошибки в проде

(8) Угу про что и речь, когда меняют нечто и хз как оно повлияет на прочее.
"Сложность программы превышает возможности программиста."

Проблема в том что тесты не показывают того что не предусмотрел разработчик тестов.

(9) А ещё они не покажут архитектурные ошибки, к примеру, неверный результат проведения документа.

Короче все эти TDD, BDD и прочие аджайлы со скрамами нужно только в одном случае.

Мы наняли даунов и взялись за неподъемную задачу, сделайте что нибудь чтобы дауны могли решать неподъемные им задачи пусть и с потерями.

(0) Имхо, проверка на вшивость: начнешь ли ты рассказывать сказки или честно скажешь, что не используешь :)

Написание хорошо покрывающих тестов, занимает от 50 до 200% времени написания кода.

В результате тесты оправдываются только если они пишутся один раз, а код который ими покрыт постоянно правится на лету толпой животных которые не умеют (или не могут) без тестов писать код.

(13) *без тестов писать работающий код

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

(12) Ну они сами разработчики ПО (не 1С), и, наверное, посчитали, что всё, что существует в реалиях других ПО и средств разработки ПО, должно существовать и в 1С.

(15) Ты слишком далеко зашел уже до тестов пользовательского интерфейса.

Тесты начинаются гораздо раньше, они для каждой функции/процедуры.

Например перед тем как писать содержимое Функция ДелаемА(Параметр1)
Пишется тест
Функция ТестФункцииФ()
  ТестПараметр1 = "апапа";
  ТестРезультат1 = ДелаемА(ТестПараметр1);
  Если ТестРезультат1 <> "парапапа" Тогда
    Возврат "А мы тест не прошли!";
  КонецЕсли;
КонецФункции;

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

На одной из прошлых работ было такое указание. Нажимаешь F5, база открылась? - в продакшен! :)

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

(19) :))))))) огонь!

(20) ну и плюсом почаще привлекать коллег к анализу кода, работы, другой взгляд сильно помогает

1.Непосредственное участие в проекте, весь код для тебя является родным.
2.Ответственный от исполнителя и заказчика на тестирование данных в демо и пром.эксплуатации

(19) Скорее всего в базе при запуске встроен набор хорошо покрывающих тестов.

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

(24) *при запуске по отладке

(24) >> Скорее всего в базе при запуске встроен набор хорошо покрывающих тестов.

Так и есть

(26) не совсем тестов, но проверки были

Как представлю покрытие тестами ERP, меня очень тянет выпить пару стаканов, чтобы жуть унять...

(28) Много доработок?

Функциональными тестами занимался Фёдор Езеев. Давно его не читал.

Тестировать нужно.

Тестировать тиражные вещи необходимо.

Если лень и страшно - для начала можно запускать каждый день ЖР с отбором по ошибкам, постепенно их можно и нужно свести к нулю.

В ерп 50% тестов отвалится после одного обновления, после другого еще 25% и т.д.

Теперь мне ясно почему в актуальных версиях например ут11 так много багов.
Своё тестирую сначала модульно, потом пограничные случаи для всего проекта.

(13) И в яндексе и в контуре и в гугле люди используют тестирование даже на мелких проектах и пишут код там далеко не животные.

(33) 1. Любой человек это животное.
Или там не люди код пишут "в яндексе и в контуре и в гугле" ?

2. У вас странные представления что там нижний уровень разработчиков сильно выше чем нижний в 1С.
Это совершенно не так, иначе бы они не стремились постоянно лучших нанимать но это бесполезно ибо там утекание за границу очень высоко или в другие компании.
А животные остаются ибо не могут утечь ))

(34)+ А с гуглом прикольно, там огромное множество подразделений в разных точках и разный уровень есть и индусы и прочие китайцы.

И да я же против TDD/BDD просто написал что это не всегда полезно и всегда замедляет разработку для только спецов высокого уровня на проекте, без толп низкого, которые сами не могут в уме всевозможные тестирования проводить виртуально.

(35) *я же не против TDD/BDD