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

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-тесты

См. также

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

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

2160 руб.

20.01.2022    9657    36    0    

18

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

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

3360 руб.

05.08.2024    2917    18    1    

12

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

В статье расскажем, как Sentry помогает компании Magnit Tech эффективно решать задачи оперативного выявления и анализа ошибок. Поделимся практическим опытом внедрения Sentry и объясним, почему этот инструмент превосходит другие бесплатные аналоги по функционалу и удобству использования. Рассмотрим гибкий механизм настройки оповещений об ошибках журнала регистрации, который позволяет адаптировать уведомления под конкретные нужды проектов. Объясним, как Sentry используется для мониторинга производительности базы 1С, обеспечивая стабильность работы критически важных систем. Затронем тему интеграции Sentry с системами мониторинга инфраструктуры и CDN.

17.07.2025    710    daniloffartur    1    

5

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

YAxUnit – это сравнительно молодой, но амбициозный и быстро развивающийся инструмент из мира open-source. Расскажем о ключевых этапах развития инструмента и особенностях работы над open-source проектом.

17.07.2025    1823    Жолтокнижниг    1    

18

HighLoad оптимизация Тестирование QA Системный администратор Программист Бесплатно (free)

В мире 1С импортозамещение используемых программных продуктов в первую очередь касается миграции СУБД с MSSQL на Postgres. Одна из основных проблем перехода — более «слабый» оптимизатор запросов Postgres по сравнению с MSSQL, когда запросы на MSSQL выполнялись значительно быстрее, чем на Postgres. Автор статьи разработал инструмент, который позволяет без значительных затрат выявить эти «проблемные» запросы. Основная идея подхода: конвертация на Postgres запросов, снятых при использовании MSSQL, и сравнение времени выполнения на MSSQL и на Postgres.

10.07.2025    1299    berserg    4    

7

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

Процесс тестирования в команде автора эволюционировал от ручных проверок до полноценной автоматизации с использованием современных инструментов и контейнеризации. Начав с Vanessa-ADD в качестве основного решения, команда постепенно расширила стек, включив в него Vanessa-Automation для UI-тестирования, YAxUnit для модульных проверок, Coverage41C для анализа покрытия кода, а также Gitlab CI, Allure и SonarQube для мониторинга качества и непрерывной интеграции. Статья объясняет, почему в качестве стартового инструмента была выбрана Vanessa-ADD и как удалось организовать запуск дымовых и сценарных тестов в CI-контуре на Windows-сервере. Рассмотрен вопрос анализа покрытия кода тестами: зачем потребовался подсчет и какими сложности сопровождали настройку Coverage41C в клиент-серверной архитектуре. Также автор рассказывает про переход на Docker (рассматривался готовый образ, но в итоге был создан собственный) и смену инфраструктуры с Windows и PowerShell на Linux и Bash.

27.06.2025    2036    TaGolovkina    3    

21

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

Ведущий разработчик Инфостарт Лаборатории рассказал о том, с какими сложностями сталкиваются команды разработки 1С, внедряющие у себя процессы автоматизации тестирования и о подходах и конкретных решениях, которые помогают эти проблемы обойти. Доклад прозвучал на конференции «Стачка» в Ульяновске в апреле 2025 года и был ориентирован на руководителей и тимлидов команд разработки и тестирования, а также на действующих тестировщиков.

20.06.2025    4073    kuntashov    5    

38

WEB-интеграция Тестирование QA Программист 1С v8.3 1С:Библиотека стандартных подсистем Абонемент ($m)

Mockaroo — онлайн-сервис для генерации тестовых (фейковых) данных в различных форматах. Будет полезен для разработчиков, тестировщиков, аналитиков и других специалистов, которым нужны реалистичные, но синтетические данные.

1 стартмани

12.05.2025    844    1    serg-lom89    3    

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

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


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

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