Как начать писать тесты без регистрации и СМС

11.05.22

Разработка - Тестирование QA

Данная статья рассчитана на людей, которые только хотят начать тестировать свои собственные наработки, но не до конца понимают, с чего начать. На практических примерах показывается, как можно начать тестировать свой код без использования дополнительного ПО / обработок / режимов запуска и прочего. Теории минимум, все отсылки собраны в заключении.

Кому стоит читать дальше?

"Если вам нравится лепить вместе куски кода, которые более или менее работают, и вы счастливы думать, что вам не придётся возвращаться к полученному в результате этого коду в дальнейшем - TDD (разработка через тестирование) не для вас" (с) Кент Бек [c.339]

Сказ "Жил да был программист 1С"

Жил да был программист 1С. Жил себе не тужил, работал в одной сибирской компании. И вроде всё хорошо, но что-то не давало ему покоя. То нелепая ошибка в продуктиве вылезет, то данные как-то криво пишутся. И закручинился программист, потерял покой.  

Думал, думал, ничего не надумал и пошёл тропой серой да к мудрецам, на весь свет известным, старцам google да yandex. И рассказали они ему про явление небывалое, что в народе тестированием кличут. И возрадовался программист - "Вот оно, лекарство от кручины твоей".

Пошёл он к другому старцу, что в народе infostart кличут. И стал спрашивать у него программист, дескать, слышал я про явление небывалое, что в народе тестированием кличут. Расскажи, добрый человек, как мне его к своей разработке подвязать. И начал ему старец кучу терминов показывать: TDD, BDD, vannesa-behavior, vanessa-automation, add, xUnit, CI/CD и прочие.  

И прикинул программист, сколько всего ему изучать придётся, испугался, ведь, как известно, "у страха глаза велики". И задумался он, как быть и что делать, и о результатах этих размышлений и последующих действий решил написать статью.

 

От сказки к реальности

Результатом размышлений и изысканий является одна простая мысль - для того, чтобы начать тестировать свой код, не нужно НИЧЕГО, кроме желания и среды разработки. И чтобы прийти к этой мысли, достаточно немного подумать о том, а что такое тест (в самом примитивном, простом смысле).

Тест - это алгоритм, который может проверить работоспособность другого алгоритма.

А если ещё упростить, то тест - это код, который проверяет работу кода.

Следовательно, "писать тесты" означает писать код, который будет проверять, как работает другой код. А теперь рассмотрим 2 практических примера на эту тему

 

Пример 1 - тестируем "привет, мир"

- Можно ли протестировать следующий код?

Сообщить("Привет мир");

В таком написании - можно, но не нужно. И вот почему:

  •  Цель теста - проверить работу собственного кода.  Задачи проверять работу системных методов или методов других разработчиков не стоит (разве что, если вы не уверены в корректности результата).

Вопрос, а что в этом коде написано разработчиком? Это сообщение "Привет, мир". Вот для него и можно написать тест.

 
 Шаг 1 - планируем тест
 
 Шаг 2 - делаем так, что тест проходил проверку и запускался
 
 Шаг 3 - Проводим рефакторинг, выделяя проверку в отдельный метод

 

Пример 2 - Тестируем формирование JSON

Это рабочая задача, которую я решал в марте и апреле 2022 года. Естественно, упрощённая. Итак, надо написать выгрузку  номенклатуры в JSON. Требуемый результат

{
code: "001"
}

 

Разработка без тестирования

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

 
 Обычный код выгрузки номенклатуры

Как проверяется этот код (если вообще проверяется)? Делается запуск внешней обработки и в режиме отладки начинаются исправления ошибок (алгоритм ручного тестирования пишу по памяти, извините)

  • Запуск 1 - вылетает ошибка "Не указан параметр запроса Ссылка"
    • Исправляем опечатку `"Сылка" -> "Ссылка"`
  • Запуск 2 - ошибка "поле code не найдено"
    • Исправляем, присваивая правильный псевдоним поля в запросе
  • Запуск 3 - ошибка "Ключ code не найден"?
    • [начинаем нервничать, ведь код-то простой вроде] Да как так-то? А вы случайно в ключе букву е русскую написали... блин, ладно исправляем
  • Запуск 4 - ошибки нет, но результат возврата - Неопределено
    • ДА ЧТО НЕ ТАК?! А функция `МагияПревращенияВJSON(ДанныеJSON)` ничего не возвращает (там забыли написать возврат)

Пример глупый, но в том или ином виде подобная картина возникает у любого разработчика начального или даже среднего уровня. Отдельно отмечу, как подобные циклы перезапуска влияют на программиста:

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

Теперь посмотрим, как то же самое разрабатывается и проверяется через тестирование

 

Разрабатываем с использованием тестирования

Любая разработка с тестированием начинается с того, что составляется "План тестирования", проще говоря, нужно определиться с тем, что, собственно, тестировать. Под текущую задачу требуется, как минимум, четыре теста:

 
 Шаг 0 - Выписываем какие тесты нам нужны

Важное примечание! Каждый тест должен тестировать какую-то одну функциональность и быть независимым от других тестов.
Применимо к нашему случаю - нельзя тестировать 4 разных вещи внутри одной функции,  а значит для каждой операции будет отдельная процедура/функция.

Для проверки будем использовать уже написанную нами функцию Проверить() (см. пример 1).

 
 Шаг 1 - Пишем тест "Тест структуры формирования JSON"
 
 Шаг 2 - Пишем тест "Тест корректности результата МагияПревращенияВJSON(ДанныеJSON)"
 
 Шаг 3 - Пишем тест "Тест работоспособности запроса данных из БД"
 
 Шаг 4 - Пишем тест "Тест работоспособности заполнения данных структуры"
 
 Итоговый листинг

 

Польза от подобного подхода

1. Получилось, что запрос к БД, отделён от логики обработки запроса, а логика заполнения JSON, от логики отправки, другими словами код стал слабосвязанным

2. Алгоритм разбился на атомарные функции, выполняющее ровно 1 действие

3. Начинает формироваться понимание о том, а что же такое тестирование, что такое размер теста (шаг теста)

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

 

Заключение

Как видите, начинать свой путь в тестирование, в частности в unit-тестирование достаточно легко. Просто пишите код. Не обязательно в начале пути использовать доп. фреймворки и чужие разработки.

Основные преимущества подобного подхода:

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

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

- идеолог движения Кент Бек также советует начинать ознакомление с попытки разработки своего фреймворка

Для тех, кто захочет копать дальше - полезные отсылки:

  •  подход, показанный в статье называется "test-driven development" или "разработка через тестирование".
  • Одним из идеологов данного подхода является Кент Бек, который написал книгу "Экстремальное программирование: разработка через тестирование" - очень советую к ознакомлению
    • и вообще читайте первоисточники, так картина знаний в голове будет более цельной.
  • После первичного погружения в тему, вам возможно не захочется возиться со своим фреймворком дальше, а взять уже готовый. Пока я могу отослать вас к четырём различным инструментам:

И напоследок личное мнение. Я не советую начинать с BDD, ибо этот подход имеет гораздо более высокий порог вхождения и может поначалу тяжело заходить в голову, что, в свою очередь, может запросто лишить мотивации к дальнейшему погружению в тему. К нему стоит обратиться уже после того, как вы освоились в unit-тестировании, упёрлись в его границы и хотите большего. Или когда внедряете полноценное тестирование продукта в команду. Но это тема отдельной статьи.

На этом у меня всё, большое вам спасибо за прочтение.

Тестирование QA TDD unit-тесты

См. также

Автотесты для типовых конфигураций ERP Управление предприятием 2 и Комплексная автоматизация 2 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.15.111.

2220 руб.

04.07.2022    6726    26    0    

23

Автотесты для типовых конфигураций Бухгалтерия предприятия КОРП 3.0 и Бухгалтерия предприятия 3.0 (vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.144.49.

1728 руб.

20.01.2022    6590    10    0    

9

Выполнение тестов и обработка их результатов в 1С: Тестировщик

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной статье мы рассмотрим имитацию действий пользователя 1С и протоколирование тестов в инструменте 1С: Тестировщик.

14.03.2024    1160    Koder_Line    1    

8

Создание и модификация тестов в 1С:Тестировщик

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

1С: Тестировщик позволяет создавать и модифицировать тесты для проверки функциональности программного обеспечения, гарантируя надежность и стабильность приложений. В данной статье будет рассмотрен процесс написания и модификации тестов в конфигурации системы 1С: Тестировщик, а также основные принципы и методики, которые помогут тестировщикам эффективно использовать этот инструмент для обеспечения качества программных продуктов.

23.01.2024    632    Koder_Line    1    

3

Настройка Allure для Gitlab (self-hosted)

Тестирование QA Абонемент ($m)

Заметка о том, как использовать Allure с self-hosted Gitlab, чтобы быстро и с минимальными усилиями получить удобные отчёты о результатах тестирования и навигацию внутри них.

1 стартмани

11.01.2024    1938    comptr    4    

24

Анализ документов: свертка базы, автотесты, динамика роста базы

Статистика базы данных Инструментарий разработчика Тестирование QA Платформа 1С v8.3 1С:Управление торговлей 10 1С:Управление производственным предприятием Абонемент ($m)

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

3 стартмани

29.12.2023    1111    9    RustIG    5    

7

Быстрый старт в 1С: Тестировщик

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

В данной статье мы рассмотрим начало работы, установку и подключение программы системы 1С: Тестировщик, рабочую область.

14.12.2023    2025    Koder_Line    0    

6

YAxUnit или модульное тестирование в 1С

Тестирование QA Бесплатно (free)

Почему-то, когда говорят о тестировании в 1С, в основном подразумевают пользовательское или сценарное тестирование. А модульное или юнит-тестирование незаслуженно обходят стороной. Расскажем об инструменте модульного тестирования, позволяющем писать тесты в формате текучих выражений и выполнять их в конфигураторе, EDT и на CI, а также о плагине для EDT, облегчающем написание и выполнение тестов.

16.11.2023    3766    theshadowco    7    

46
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Steelvan 302 11.05.22 10:26 Сейчас в теме
2. mixsture 17.05.22 15:01 Сейчас в теме
Все хорошо в тестировании, но основная боль в том, что код в 20 строчек превратился в 3 страницы. И ведь это пока что unit тесты - одни из самых малозатратных в написании. Кроме самого времени на декомпозицию и кодинг (с не такими уж простымим концепциями замены реальных объектов mock-версиями) - возможные баги в 20 строчках кода обогатились возможными багами коде тестирования. Соответственно, встает вопрос - за чей счет этот банкет?
3. zeltyr 566 17.05.22 19:22 Сейчас в теме
(2) О, это дискуссия о которую уже сломано множество копий. И ответ, в среднем, примерно следующий (он, кстати, есть в книге того же Кента Бэка), далее выдержка из его книги
Сколько нужно тестов?
- Чёткого правила нет. Выбирается исходя из собственного опыта и рассуждений
- Можно пробовать оценить приемлемое *среднее время между сбоями* (MTBF, Mean Time Between Failures). Если предполагаемая аномалия увеличивает MTBF кратно, значит имеет смысл уделить время разработке теста (даже если событие маловероятно, но возникновение которого приводит к такому увеличению)
- Когда тесты писать не нужно - тогда, когда знание особенностей реализации без какого-либо теста даёт уверенность в том, что код работает правильно

- Тесты - это средство достижения цели
- Цель: код, в корректности которого мы в достаточной степени уверены


Дополню некоторыми своими мыслями:
- когда ты учишься - тесты пишутся на всё - у меня, например, есть тесты, которые проверяют корректность созданных метаданных. Но это нормально на этапе входа и делается это на фанатизме, в том числе и в неучитываемое рабочее время.
- тесты - это автоматизация, а автоматизация это всегда хорошо.
- тесты облегчают повторные проверки модифицированных участков кода. Н-р: у нас идёт внедрение и требования к выгрузке той самой номенклатуры менялись несколько раз. Я вносил изменения в код, дописывал тесты и у меня автоматом проверялась вся выгрузка, ведь один раз написанные тесты сделают это за тебя. И именно так нашлись неучтённые мной косяки в коде, в том числе и в корректности заполнения полей выгрузки.
- по поводу "за чей счёт банкет" - это затратно только на этапе входа. Освоив какой-нибудь фреймворк и средства автоматизации запуска тестирования - замечаю, что время на разработку уходит не то, чтобы сильно больше, а может даже и меньше. А вот качество повышается очень и очень сильно.
- Ты начинаешь проводить больше времени в конфигураторе, а не в предприятии. Поясню. Я использую сейчас фреймворк xddRunner. Я написал логику и тесты, дальше я запускаю батничек, который прогоняет все тесты и запускает отчет в аллур. А я в это время возвращаюсь в конфигуратор и дальше пишу код. Я сам руками почти в режим предприятия не хожу, только для какой-то минорной отладки, что экономит мне время.

Это вот мои выводы после двух месяцев плотного погружения в разработку через тестирование. Мне понравилось, я втянулся и отказываться от этой практики пока не вижу смысла.
Cmapnep; milov.aleksey; +2 Ответить
4. Vovan58 65 13.05.23 12:12 Сейчас в теме
причем тут регистрация и СМС?
5. zeltyr 566 26.05.23 11:03 Сейчас в теме
(4) незатейливый солдатский юморок, не более
Оставьте свое сообщение