Базовое руководство по автоматизации тестов MySQL

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

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

Давайте посмотрим, как это можно сделать и как проверить результаты теста.

Вывод тестового сценария

Во-первых, давайте вспомним вывод нашего тестового скрипта:

То есть результат каждого текста представляется в виде строки:

[TEST]                                      <Test name> [<Result>]

[TEST] - признак того, что строка является результатом теста, нужна для возможности фильтровать результаты теста из вывода других команд, подробнее это рассмотрим ниже.< /p>

<Имя теста> - название теста

[<Result>] - результат теста, OK или FAILED, вы можете установить любые другие значения для отображения пройденных или не пройденных тестов.

Нам нужно запустить скрипт из командной строки, не запрашивая никакой информации у пользователя.

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

Это можно сделать с помощью следующей команды:

mysql_config_editor set --login-path=local_test --host=localhost --port=3306 --user=test --password

При его выполнении нам нужно будет один раз ввести пароль, он сохранится в обфусцированном виде в файле .mylogin.cnf, а потом уже запрашиваться не будет (подробнее здесь).

В этом случае мы запустим скрипт командой:

mysql --login-path=local_test --database=employees --raw -s < tests.sql

На самом деле вывод скрипта будет выглядеть так:

Здесь вы можете заметить первую строку, содержащую результат вызова функции get_employees.

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

Есть возможность отфильтровать ненужные строки, оставив только строки с результатами проверки.

В этом случае это можно сделать, используя подстроку «[TEST]» в приведенных выше примерах в качестве фильтра для команды grep, позже я покажу код для этого.

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

Обработка результатов

Для удобства сохраним вывод скрипта и код возврата mysql в переменные RESULTS и SCRIPT_RESULT:

RESULTS=$(mysql --login-path=local_test --database=employees --raw -s < tests.sql)
SCRIPT_RESULT=$?

Переменная SCRIPT_RESULT будет равна 0, если скрипт SQL был успешно выполнен (нет ошибок в коде, выполняющем тестовый скрипт), и 1 в случае ошибок.

Этот результат не следует путать с результатом самих тестов.

Для проверки успешного выполнения самих тестов не должно быть Failed тестов, то есть не должно быть строк тестов с результатом [FAIL], это можно проверить командой:

TEST_RESULT=$(echo "$RESULTS" | grep -F "[TEST]" | grep -F "[FAIL]" | wc -l)

Здесь мы берем результаты работы скрипта, выбираем только строки с результатами тестов, а затем подсчитываем количество строк, содержащих «[FAIL]», то есть количество неудачных тестов.

0 будет означать, что все тесты прошли успешно, и общий результат теста можно считать успешным.

Протестируйте скрипт тестирования

Соберем описанные команды в один скрипт:

#!/bin/bash
RESULTS=$(mysql --login-path=local_test --database=employees --raw -s < tests.sql)

SCRIPT_RESULT=$?

TEST_RESULT=$(echo "$RESULTS" | grep -F "[TEST]" | grep -F "[FAIL]" | wc -l)

echo SCRIPT_RESULT: $SCRIPT_RESULT
echo TEST_RESULT: $TEST_RESULT

Давайте запустим его и посмотрим на результат:

$ ./tests.sh
SCRIPT_RESULT: 0
TEST_RESULT: 0

В этом случае команда mysql выполнялась без ошибок и все тесты были пройдены.

Для наглядности вызовем сначала ошибку в команде mysql, например, при попытке выполнить несуществующий файл с тестами:

RESULTS=$(mysql --login-path=local_test --database=employees --raw -s < nonexisting_file.sql)

Результат скрипта:

$ ./tests.sh
./tests.sh: line 2: nonexisting_file.sql: No such file or directory
SCRIPT_RESULT: 1
TEST_RESULT: 0

Или указать несуществующую базу данных:

RESULTS=$(mysql --login-path=local_test --database=nonexisting_database --raw -s < tests.sql)

$ ./tests.sh
ERROR 1044 (42000): Access denied for user 'test'@'localhost' to database 'nonexisting_database'
SCRIPT_RESULT: 1
TEST_RESULT: 0

Мы видим, что при запуске шелл-скрипта генерируются различные ошибки, но в обоих случаях это приводит к тому, что у нас в переменной SCRIPT_RESULT число, отличное от 0.

Мы можем обработать это условие и выполнить соответствующие действия.

Вернем строку обратно, чтобы скрипт отработал успешно:

RESULTS=$(mysql --login-path=local_test --database=employees --raw -s < tests.sql)

Теперь давайте проверим ситуацию, когда есть неудачные тесты.

Закомментируем одну из строк, выполняющих удаление в тесте «Очистка»:

-- DELETE FROM employees WHERE emp_no = @emp_no;

И запустите скрипт:

$ ./tests.sh
SCRIPT_RESULT: 0
TEST_RESULT: 1

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

Анализируя SCRIPT_RESULT и TEST_RESULT, вы можете контролировать процессы выполнения тестов, развертывания, оповещения пользователей и т. д.