Раніше я вважав, що в 1С неможливо юніт-тестування (адже тут немає всюдисущих об'єктів, звичних класів і і. Т.). Іноді на Інфостарте з'являлися спеціалізовані обробки, але часто вони швидше відлякували від теми тестування, ніж залучали до неї. Потім я дізнався про xUnitFor1C. Виявилося, що тестування в 1С в загальному не так вже й складно, навіть в порівнянні з іншими мовами. У даній статті я розповім про свій перший досвід.
Хочу висловити подяку за статтю so-quest. Саме вона виявилася необхідним поштовхом для вивчення xUnitFor1C, про роботу з яким і піде мова нижче.
А так-же розробникам xUnitFor1C за чудовий набір інструментів.
xUnitFor1C е то набір зовнішніх обробок 1с, що полегшують, а головне, що упорядковують тестування. У цій статті буде використовуватися тільки xddTestRunner.epf (тестів виполнятель).
Розробляється обробка для ведення логів роботи робота і виведення клікабельно звіту. Додатковою складністю є висновок до звіту службових повідомлень, що виникли в процесі роботи робота (наприклад, при проведенні документів). Застосуємо "розробку через тестування".
Готуємо оточення.
Набір тестів - це обробка, содержащаа експортну функцію ПолучітьспісокТестов (ЮнітТестірованіе). У документації запропонований шаблон такої обробки. Створюємо її і зберігаємо. Модуль обробки виглядає так:
Запускаємо xddTestRunner.epf. Для мене інтерфейс виявився несподівано дружелюбним. Завантажуємо тести з каталогу. Перевіряємо. Повинен з'явитися один тест. Тест повинен провалитися. Виправляємо тест.
Тепер тест повинен пройти успішно.
Цикл розробки.
1) Створюємо непрацюючий тест
Перезавантажуємо список тестів, перевіряємо тестів тепер 2 і другий провалився.
2) Робимо рівно стільки, щоб тест пройшов успішно.
Сода табличну частину в обробці з полями "виконана" і "текст".
Додаємо в модуль
Перевіряємо, що тест пройшов.
3) Рефакторинг.
При такому підході код відразу покритий тестами, і його можна змінювати, не боячись, що у змін будуть "невраховані наслідки".
Згідно TDD кроки 1,2,3 постійно повторюються, причому тривалість ітерації повинна бути якомога менше.
Незалежність тестів.
Для забезпечення незалежності передбачені наступні процедури:
При необхідності повторити.
При необхідності повторити знову ..
Повністю процес написання можна подивитися по коммітов в репозиторії на github
Чи не знайшов як зробити скачування безкоштовним, так що в тому репозиторії є і прикладений до статті архів.
Дякую за увагу, сподіваюся знайдуться люди які після цієї статті візьмуть на озброєння описані принципи і світ стане трішки краще.
P.S. Хто тут?
Коли постає питання "як скласти запит", "як зробити друковану форму", відповідь тут же знаходиться. Зрештою, можна подивитися, як це зроблено в типовій конфігурації. Але коли з'явилися питання "А що ж мені писати в тести? А як тестувати звіти? А керовані форми? А запис в базу?" в типових конфігураціях відповідей я не знайшов. Ну і довелося винаходити свої милиці ..
Але ж хтось вже застосовує ці підходи (раз хтось написав xddTestRunner). Напевно цей хтось стикався з багатьма труднощами і вирішив їх. Тому на випадок, якщо комусь захочеться виговоритися, доклав ще одну обробку, в якій не все так гладко і красиво вийшло. Сподіваюся на конструктивну критику і посилання на почуття. =)