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

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

См. также

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

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

2160 руб.

05.08.2024    1277    12    1    

7

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

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

2400 руб.

04.07.2022    8368    38    1    

29

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

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

1800 руб.

20.01.2022    7783    19    0    

13

Облачные сервисы, хостинг Linux Тестирование QA Сервера Системный администратор Программист Платформа 1С v8.3 Бесплатно (free)

Завершающая публикация цикла "В облако на работу:.. Рецепты от Капитана", в ходе которых был собран полнофункциональный рабочий контур 1С в сети на отечественной Ред ОС. С веб-серверами, доменной авторизацией, архивированием, отказоустойчивостью и прочая, прочая... В этой статье мы определяемся с быстродействием системы, проводим нагрузочное тестирование и отпускаем ее в свободное плавание (зачеркнуто) выпускаем ее в продуктовый контур, где, конечно же, придется отлавливать ошибки, мониторить состояние и т.п.

31.10.2024    1308    capitan    0    

0

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

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

21.10.2024    2780    leemuar    8    

22

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

Пишете много тестов – хорошо. Покрытие достаточно высокое – отлично. Но баги все равно попадаются – плохо. Раз юниты и фича-файлы – это код, значит, их можно протестировать. Расскажем о подходе «мутационное тестирование», позволяющем оценить надежность тестов и повысить к ним доверие.

30.08.2024    1292    Scorpion4eg    6    

7

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

Иногда возникают ситуации, когда надо развернуть тестовую базу клиента / свою на серверах Windows или Linux. Тестовые базы могут понадобиться в разных ситуациях: у клиента ошибка, на нашей базе она не воспроизводится, реализуем новый функционал и хотелось бы протестировать на Linux и т.д. А теперь представим, что это все на потоке. Что тестовых баз 1С не одна, а 20-30. И получаем проблему, что непонятно, занята она сейчас кем-то или нет. Предлагаю вариант решения этой проблемы.

28.06.2024    1511    Diversus    12    

5
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Steelvan 306 11.05.22 10:26 Сейчас в теме
2. mixsture 17.05.22 15:01 Сейчас в теме
Все хорошо в тестировании, но основная боль в том, что код в 20 строчек превратился в 3 страницы. И ведь это пока что unit тесты - одни из самых малозатратных в написании. Кроме самого времени на декомпозицию и кодинг (с не такими уж простымим концепциями замены реальных объектов mock-версиями) - возможные баги в 20 строчках кода обогатились возможными багами коде тестирования. Соответственно, встает вопрос - за чей счет этот банкет?
3. zeltyr 607 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 607 26.05.23 11:03 Сейчас в теме
(4) незатейливый солдатский юморок, не более
Оставьте свое сообщение