Visualización de cobertura de autotest para servicios gRPC / Sudo Null IT News
Introducción
En este artículo quiero hablar de una herramienta para medir la cobertura de los servicios gRPC. herramienta-de-cobertura-de-pruebasescrito en lenguaje golang. La tarea principal de la herramienta es medir automáticamente la cobertura de requisitos en función de prototipo contratos. Hablemos del uso en autotests, el concepto, informe y brevemente sobre la arquitectura de la herramienta en sí. herramienta-de-cobertura-de-pruebas
Existen dos tipos de cobertura: según código, según requisitos. Este artículo habla de una herramienta que está enfocada a medir coberturas según requerimientos. Los requisitos en este caso son prototipo contratos. En consecuencia, todas las métricas y análisis se construirán en torno a protocontratos; esta herramienta no podrá medir la cobertura de los requisitos desde la lógica empresarial profunda del servicio.
Al desarrollar y probar servicios gRPC, es fundamental garantizar que las pruebas automáticas cubran todos los escenarios de interacción clave entre el cliente y el servidor. Como mínimo, debe asegurarse de que todos los métodos del servicio gRPC estén cubiertos por pruebas automáticas y, como máximo, que todos los campos de respuesta/solicitud estén completamente verificados por pruebas automáticas. Sin embargo, esta tarea se vuelve más complicada a medida que crece el número de servicios: docenas y, a veces, cientos de métodos que pueden cambiar con cada nueva versión. Los cambios constantes en los contratos requieren una adaptación oportuna de las pruebas automatizadas. Herramienta herramienta-de-cobertura-de-pruebas ayuda a evaluar objetivamente el estado actual de la cobertura y, en base a esto, sacar conclusiones sobre la necesidad de escribir/cambiar pruebas automáticas.
Ventaja importante de la herramienta. herramienta-de-cobertura-de-pruebas es que la cobertura de siniestros se cobra automáticamente: todo lo que se necesita es la configuración correcta.
Importante. Quizás el artículo parezca complicado para algunos lectores: hago esta suposición basándome en la popularidad de los servicios REST y el uso del protocolo HTTP/1.1 es aún menos común; Por lo tanto, le recomiendo de inmediato que se familiarice con los enlaces a continuación:
También observo que incluso si la herramienta herramienta-de-cobertura-de-pruebas Diseñado para servicios gRPC y escrito en golang, la esencia y el principio no cambian, exactamente la misma herramienta se puede escribir en cualquier otro idioma con soporte gRPC. El concepto mismo de medir la cobertura “por contrato” también se puede aplicar al protocolo HTTP/1.1, junto con pavonearse documentación.
Todo lo que se describe a continuación tiene aplicación práctica en un proyecto real. En la sección “Aplicación práctica” compartiré mi experiencia y hablaré sobre posibles áreas de aplicación.
Concepto
Veamos el concepto básico. herramienta-de-cobertura-de-pruebas. El propósito de la herramienta es comparar los contratos esperados con los reales. Los contratos esperados se toman de reflexión servicio que se está probando. Los contratos reales se recopilarán cuando se ejecuten las pruebas automáticas. Todo es bastante simple y claro, existen ciertas dificultades con la implementación, pero todas estas dificultades se resuelven a nivel de código.
El propósito de esta sección también es hacer las preguntas correctas sobre la cobertura del contrato proto. Durante el artículo mostraré cómo la herramienta herramienta-de-cobertura-de-pruebas ayuda a responder estas preguntas.
Para comprender más fácilmente el principio de funcionamiento de la herramienta, considere contrato sencillo servicio de gestión de artículos ArtículosServicio:
service ArticlesService {
rpc GetArticle (GetArticleRequest) returns (GetArticleResponse);
rpc CreateArticle (CreateArticleRequest) returns (CreateArticleResponse);
rpc UpdateArticle (UpdateArticleRequest) returns (UpdateArticleResponse);
rpc DeleteArticle (DeleteArticleRequest) returns (DeleteArticleResponse);
}Este contrato describe el servicio lógico. ArticlesService y varios métodos GetArticle, CreateArticle, UpdateArticle, DeleteArticle. Desde el punto de vista de la automatización de pruebas, debemos responder las siguientes preguntas:
¿Cuál es el porcentaje de cobertura del servicio lógico general?
¿Qué métodos de servicio lógicos están cubiertos por las pruebas automáticas? ¿Qué porcentaje está cubierto todo el servicio lógico?
¿Qué métodos están en desuso y no deberíamos escribir pruebas automáticas para ellos?
Definamos inmediatamente la terminología. servicio lógico. En la práctica, una aplicación puede contener varios servicios lógicos, por ejemplo, en un host localhost:3000 Puede haber varios servicios lógicos a la vez: ArticlesService, UserService, AccountService etc. En consecuencia, desde el punto de vista de medir la cobertura, tiene sentido trabajar individualmente con cada servicio lógico dentro de una aplicación.
Ahora echemos un vistazo más de cerca al método. GetArticleque acepta la solicitud GetArticleRequest:
// Обычно в запросе передаётся не так много полей: идентификаторы, фильтры, либо пустой запрос
// В таком случае, наверняка, все поля будут покрыты автотестами, и покрытие достаточно легко оценить
// К сожалению, не всегда всё проходит так гладко, как хотелось бы
// В моей практике встречаются методы, которые принимают десятки полей в запросе, содержат enum-ы и вложенные структуры
// В таких случаях оценить покрытие "на глаз" становится крайне сложной задачей
// Именно здесь на помощь приходит инструмент измерения покрытия
message GetArticleRequest {
string article_id = 1;
}Y devuelve la respuesta GetArticleResponse:
message GetArticleResponse {
// Важно проверять все варианты, то есть у нас должны быть автотесты на ошибку и на успешный ответ
oneof result {
Error error = 1; // Error это отдельная модель. Необходимо проверять каждое поле внутри данной модели
Article article = 2; // Article это также отдельная модель
}
}Hay ciertos parámetros/campos en los modelos de solicitud y respuesta, p. GetArticleRequest Este article_idy en GetArticleResponse uno de los campos puede ser devuelto error, article. Al mismo tiempo Error, Article También se trata de modelos con estructura y encajamiento propios. Echemos un vistazo más de cerca al modelo. Error:
// Для нас очень важно понимать, какие именно значения enum-ма протестированы
// На этом может быть завязана критичная бизнес логика
enum ErrorType {
NOT_FOUND = 0;
ALREADY_EXISTS = 1;
UNSPECIFIED = 2;
}
message Error {
string message = 1; // Примитивный тип строки
ErrorType type = 2; // А это уже enum с определенными значениями
}
Vemos que el modelo Error contiene campos: message – línea, type – enumeración, también necesitamos entender si estos campos están cubiertos por pruebas automáticas. Tenga en cuenta que el campo tipo dentro del modelo Error tiene tipo ErrorType — Esta es una enumeración/enumeración, que también debe estar cubierta por pruebas automáticas y me gustaría ver qué valores de enumeración específicos están cubiertos. Como resultado, desde el punto de vista de la automatización de pruebas, debemos responder las siguientes preguntas:
¿Cuántos campos hay en la respuesta/solicitud y cuántos de ellos están cubiertos? ¿Qué porcentaje de campos están cubiertos?
¿Qué campos específicos están cubiertos por las pruebas automáticas? Me gustaría ver todo el anidamiento de campos, incluidas las enumeraciones. En el ejemplo anterior hay campos
error,articleMe gustaría saber si tenemos pruebas automáticas que verifican si hay un error y una solicitud exitosa.¿Qué campos están en desuso y no deberíamos escribir pruebas automáticas para ellos?
Responderemos a todas las preguntas anteriores en la sección “Informe”.
Arquitectura
herramienta arquitectónica herramienta-cobertura-pruebas consta de dos proyectos:
herramienta-cobertura-pruebas — la herramienta en sí, el proyecto contiene todas las funciones, comandos, paquetes necesarios, interceptador para integración en pruebas automáticas;
pruebas-cobertura-informe – un metaproyecto que se utiliza sólo como submódulo‑я y proporciona una plataforma para generar informes, puedes leer qué es un submódulo en git aquí. Informe de Sam escrito en reaccionar + mecanografiado y se compila en un único archivo HTML listo para su uso. Al generar un informe, el estado requerido se inserta en el archivo HTML y se obtiene un informe HTML listo para usar.
No entraremos en detalles sobre la implementación de la herramienta; creo que este es un tema para un artículo aparte. Me gustaría detenerme con más detalle solo en la implementación del interceptor. CoberturaInterceptor:
package coverageinupt
import (
// Стандартные go-шные библиотеки
"context"
"fmt"
"log"
// Настройки и утилиты из библиотеки tests-coverage-tool
"github.com/Nikita-Filonov/tests-coverage-tool/tool/config"
"github.com/Nikita-Filonov/tests-coverage-tool/tool/utils"
// Библиотека uuid для генерации названия файла с результатами покрытия
"github.com/google/uuid"
// Библиотека для работы с gRPC протоколов в golang. В данном случае нам нужны только типы из этой библиотеки
"google.golang.org/grpc"
)
func CoverageInterceptor() grpc.UnaryClientInterceptor {
return func(ctx context.Context, method string, req, reply interface{}, cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
invokerErr := invoker(ctx, method, req, reply, cc, opts...)
// Собираем результат покрытия из данных gRPC перехватичка: метод, запрос, ответ
result, err := buildCoverageResult(method, req, reply)
if err != nil {
// Если результат собрать не получилось, пишем лог об ошибке, но ничего не фейлим
// Так сделано специально, чтобы никак не блокировать выполнение автотеста
log.Printf("Error building coverage result: %v", err)
return invokerErr
}
// Получаем настройки, чтобы понимать, куда нужно сохранить результат покрытия
toolConfig, err := config.NewConfig()
if err != nil {
// Также в случае ошибки ничего не фейлим, просто пишем лог
log.Printf("Error building config: %v", err)
return invokerErr
}
// Сохраняем результат покрытия в JSON файл
filename := fmt.Sprintf("%s.json", uuid.New().String())
resultsDir := toolConfig.GetResultsDir()
if err = utils.SaveJSONFile(result, resultsDir, filename); err != nil {
// Также в случае ошибки ничего не фейлим, просто пишем лог
log.Printf("Error saving coverage result: %v", err)
}
return invokerErr
}
}Ajustes
Para el correcto funcionamiento de la herramienta herramienta-de-cobertura-de-pruebas debe especificar la ruta a archivo YAML con configuración, para esto necesita configurar la variable de entorno TESTS_COVERAGE_CONFIG_FILE:
export TESTS_COVERAGE_CONFIG_FILE="./examples/config-example.yaml"Ahora veamos cómo debería verse el archivo YAML con la configuración:
# Список сервисов, для которых необходимо измерять покрытие
services:
- name: "first service" # Название сервиса — мета информация для корректного отображение в отчете
host: "localhost:1000" # Адрес gRPC сервиса
repository: " # Ссылка на репозиторий — мета информация для корректного отображение в отчете
- name: "second service"
host: "localhost:2000"
repository: "
- name: "third service"
host: "localhost:3000"
repository: "
# Настройки ниже опциональны
# Все значения указанные ниже являются стандартными, то есть будут использоваться по умолчанию
# При необходимости настройки можно изменить через yaml файл или через переменные окружения
# Переменная окружения "TESTS_COVERAGE_RESULTS_DIR"
resultsDir: "." # Директория, в которую будут сохраняться файлы с результатами покрытия
# Переменная окружения "TESTS_COVERAGE_HTML_REPORT_DIR"
htmlReportDir: "." # Директория, в которую будет сохранен HTML отчет
# Переменная окружения "TESTS_COVERAGE_JSON_REPORT_DIR"
jsonReportDir: "." # Директория, в которую будет сохранен JSON отчет
# Переменная окружения "TESTS_COVERAGE_HTML_REPORT_FILE"
htmlReportFile: "index.html" # Имя HTML файла отчета
# Переменная окружения "TESTS_COVERAGE_JSON_REPORT_FILE"
jsonReportFile: "coverage-report.json" # Имя JSON файла отчетаImportante. La configuración del archivo YAML tiene prioridad sobre la configuración pasada a través de variables de entorno. Por ejemplo, si el archivo YAML indica htmlReportFile: "index.html"y en variables de entorno TESTS_COVERAGE_HTML_REPORT_FILE="report.html"entonces el valor final será índice.html.
Puedes obtener más información sobre todas las configuraciones. aquí. Ejemplo de archivo yaml con configuración.
Integración en autotests
La integración en las pruebas automáticas es lo más sencilla posible y se realiza con una línea de código: mediante un interceptor. CoberturaInterceptor. Veamos un ejemplo de una prueba automática que utilizará el contrato de servicio descrito anteriormente. ArtículosServicio:
package test
import (
// Стандартные go-шные библиотеки
"context"
"crypto/tls"
"fmt"
"log"
"testing"
// Библиотека, которая поможет интегрировать перехватчик CoverageInterceptor в клиентское соедениение
grpcmiddleware "github.com/grpc-ecosystem/go-grpc-middleware"
// Библиотека для работы с gRPC протоколов в golang
// С помощью данной библиотеки мы создаим клиентское соедение с gRPC сервером
"google.golang.org/grpc"
"google.golang.org/grpc/credentials"
// Сама библиотека tests-coverage-tool, из нее нам нужен перехватчик CoverageInterceptor
"github.com/Nikita-Filonov/tests-coverage-tool/tool/coverageinupt"
// Я не укзавал импорты для прото контрактов ArticleService, считаю это бессмыслено
// На практике у вас, как и у меня будут другие контракты реальных проектов
// В данном контексте важно лишь показать интеграцию перехватика CoverageInterceptor
)
func TestGetArticle(t *testing.T) {
// Настройка клиентского соединения gRPC
conn, err := grpc.Dial(
"localhost:1000", // Указываем адрес тестируемого приложения
grpc.WithTransportCredentials(credentials.NewTLS(&tls.Config{InsecureSkipVerify: true})),
grpc.WithUnaryInterceptor(
grpcmiddleware.ChainUnaryClient(
// Указываем CoverageInterceptor для сбора покрытия
// Это единственная строчка кода, которую нужно добавить для сбора покрытия
coverageinupt.CoverageInterceptor(),
),
),
)
if err != nil {
log.Fatalf("Failed to connect to gRPC server: %v", err)
}
defer conn.Close()
// Инициализируем ArticleService из proto контрактов
client := articleservice.NewArticleServiceClient(conn)
// Вызываем gRPC метод; данные о покрытии будут автоматически сохранены в директорию указанную в настройках
resp, err := client.GetArticle(context.Background(), &articleservice.GetArticleRequest{})
fmt.Println(resp, err)
}
Después de ejecutar la prueba automática en el directorio resultados-de-cobertura Los resultados de la cobertura se guardarán en el siguiente formato:
{
"method": "company.team.v1.ArticleService.GetArticle",
"request": (
{
"covered": false,
"parameter": "article_id",
"deprecated": false
}
),
"response": (
{
"covered": true,
"parameter": "article",
"parameters": (
{
"covered": true,
"parameter": "id",
"deprecated": false
},
{
"covered": true,
"parameter": "title",
"deprecated": false
},
{
"covered": true,
"parameter": "author",
"deprecated": false
},
{
"covered": true,
"parameter": "description",
"deprecated": false
}
),
"deprecated": false
},
{
"covered": false,
"parameter": "error",
"parameters": (
{
"covered": false,
"parameter": "message",
"deprecated": false
},
{
"covered": false,
"parameter": "type",
"deprecated": false,
"parameters": (
{
"covered": false,
"parameter": "NOT_FOUND",
"deprecated": false
},
{
"covered": false,
"parameter": "ALREADY_EXISTS",
"deprecated": false
},
{
"covered": false,
"parameter": "UNSPECIFIED",
"deprecated": false
}
)
}
),
"deprecated": false
}
)
}
No nos detendremos en la estructura del resultado; es bastante simple y comprensible; El código de inicio de la propia estructura se encuentra aquí.
Interesante. Al abordar el guardado de resultados en archivos, puede surgir una pregunta natural: ¿esto afecta el tiempo de ejecución de las pruebas automáticas? Es lógico que sí, tiene efecto, pero, como muestra la práctica al utilizar la herramienta, no mucho. Esto agregará unos milisegundos a la ejecución de cada solicitud; todo, por supuesto, dependerá en gran medida del tamaño del contrato y del entorno en el que se ejecutan las pruebas automáticas. Al integrar la herramienta en nuestras pruebas automáticas, no notamos un aumento en el tiempo de ejecución, a pesar de que nuestros contratos son bastante grandes, en promedio entre 10 y 50 campos por solicitud y entre 300 y 1200 campos por respuesta. Por lo tanto, podemos concluir que incluso si el tiempo de ejecución de cada solicitud aumenta, es sólo ligeramente: unos pocos milisegundos.
Informe
Para generar un informe necesita:
Resultados de cobertura de carpeta resultados de coberturaque se obtuvieron al ejecutar autotests. En nuestro ejemplo, estos resultados se obtuvieron en la sección “Integración en Autotests”;
Especifique la ruta al archivo YAML con la configuración a través de la variable de entorno “TESTS_COVERAGE_CONFIG_FILE”. En consecuencia, yo mismo Archivo YAML con configuración;
Por último, pero no menos importante. Para el correcto funcionamiento de la herramienta herramienta-cobertura-pruebas es necesario que el servicio gRPC que se está verificando admita reflexión.
Ahora que todos los componentes necesarios están ensamblados, puede generar un informe. Instalar herramientas-cobertura-pruebas, después de la instalación generamos un informe:
go install github.com/Nikita-Filonov/tests-coverage-tool/...@latest
tests-coverage-tool save-reportEquipo guardar informe cargará los protocontratos esperados usando reflexión y los compara con los resultados reales en la carpeta de resultados de cobertura. Los informes HTML y JSON se guardarán en las carpetas especificadas en la configuración. De gran interés informe HTMLya que es él quien visualiza todo el panorama de cobertura. El informe JSON contiene información que se puede utilizar para recopilar análisis, enviar resultados al chat de trabajo, etc. También vale la pena señalar que el informe HTML se genera en un único archivo HTML, lo cual es muy conveniente y abre grandes oportunidades para más trabajar con ello. Por ejemplo, un informe HTML se puede descargar de trabajos/artefactos de canalización y abrir localmente en el navegador, o publicarse en GitLab/Páginas de GitHub o simplemente enviarlo como un archivo a un colega en un chat de trabajo.
Ahora echemos un vistazo más de cerca a en qué consiste un informe HTML. Se puede encontrar un ejemplo actual de un informe. aquí.
Importante. Antes de comenzar la historia sobre el informe HTML, quiero advertirles que los datos en las capturas de pantalla son datos de prueba que pueden ser incoherentes y contradictorios, la tarea principal es mostrar la pantalla.
Lo primero de lo que quiero hablar es de la barra de aplicaciones en el encabezado del informe. La barra de aplicaciones contiene un conjunto mínimo de funcionalidades; lo más interesante es la posibilidad de seleccionar el servicio cuya cobertura queremos ver:
A continuación hay dos widgets, uno muestra información sobre el servicio y la fecha en que se creó el informe. El segundo widget muestra la cobertura general del servicio como porcentaje. Tenga en cuenta que en este contexto nos referimos a la cobertura general de un servicio/aplicación, dentro de la cual puede haber varios servicios lógicos:
A continuación se muestra un widget grande que muestra la cobertura total para cada servicio lógico:
Luego viene el widget más interesante: una tabla que cubre los métodos de servicio lógicos. Arriba, en la sección “Concepto”, hemos formulado preguntas para las que queremos ver respuestas en el informe:
En la captura de pantalla siguiente, la columna “Método” muestra el nombre del método. En la columna “¿Cubierto?” el estado de cobertura es visible;
La columna “Total de casos” muestra de cuántos casos se recopilaron estadísticas. Por ejemplo, podemos tener varias pruebas automáticas para un método, lo que significa que habrá varias llamadas a métodos;
Las columnas “Parámetros totales de solicitud/Cubiertos” y “Parámetros totales de respuesta/Cubiertos” muestran el número total de campos, el número de campos cubiertos y el porcentaje de cobertura para la solicitud y la respuesta, respectivamente;
En la esquina superior derecha hay una escala que muestra el porcentaje general de cobertura del servicio lógico;
Prima. Puede filtrar los resultados de cobertura para cada servicio lógico haciendo clic en el icono de filtro en la esquina superior derecha. También está disponible la clasificación por todas las columnas de la tabla.
Para cada método puedes ver información más detallada. En el árbol de campos de solicitud/respuesta puede ver exactamente qué campos se cubrieron. Si el campo está en desuso, se mostrará junto a (en desuso). Además, para las enumeraciones, se mostrará una lista de todos los valores posibles y el estado de cobertura de cada valor. El árbol de campos proporciona información muy útil para un análisis detallado de la cobertura. Puede ver qué no está cubierto, qué asignaciones/campos/enumeraciones no están cubiertos y qué pruebas automáticas deben agregarse. Tenga en cuenta que algunos campos muestran un icono amarillo con un signo de exclamación al lado. Esto significa que el campo actual está cubierto, pero hay campos descubiertos en sus hijos. Esta notación simplifica la búsqueda de parámetros descubiertos y hace que este proceso sea más visual. La falta de controles para ciertos campos son errores potenciales:
Importante. Me gustaría hablar con un poco más de detalle sobre cuándo se considera cubierto un campo. Se trata de la herramienta herramienta-cobertura-pruebas escrito en golang, en golang todos los tipos primitivos tienen valores estándar/valor cero, por ejemplo, para tipo cadena el valor predeterminado será la cadena vacía “”, para el tipo booleano el valor predeterminado será falso, por entero el valor estándar será 0, se pueden encontrar más detalles aquí. De esta forma, un campo se considera cubierto cuando su valor era diferente al estándar. Por ejemplo, tenemos un campo es_usuario_activo y si hay un autotest que comprueba que el campo es verdadero, entonces el campo se considerará cubierto.
Aplicación práctica
Hay muchas opciones para aplicar y analizar la cobertura y esta tarea recae enteramente en el usuario de la herramienta. herramienta-de-cobertura-de-pruebas – es decir, para un ingeniero de control de calidad. Daré ejemplos de cómo mi equipo usa la herramienta y también brindaré oportunidades potenciales de uso:
Ejemplo personal de uso. En mi equipo, la herramienta se utiliza de la siguiente manera: después de escribir pruebas automáticas para nuevas funciones, el ingeniero de control de calidad verifica el informe de cobertura y verifica si olvidó verificar todos los campos de solicitud y respuesta. Si se omitió alguna verificación, se agregan pruebas automáticas. Esto también reduce en gran medida el tiempo dedicado a revisar la lógica empresarial que se está probando; utilizando el informe de cobertura, puede comprender objetivamente lo que se está verificando en las pruebas automáticas; Todo esto da mucho conciencia al redactar pruebas automatizadas, así como una evaluación objetiva de la cobertura para todo el equipo;
Ampliación de cobertura. Una aplicación potencial es analizar pruebas automáticas existentes y aumentar la cobertura escribiendo otras nuevas o ajustando pruebas automáticas antiguas. Con un informe HTML, puede ver qué métodos no se cubrieron con las pruebas automáticas, qué campos de solicitud/respuesta no se cubrieron y qué valores de enumeración no se cubrieron. En base a estos datos, puede crear tareas de automatización. Mi equipo no tiene tal proceso; escribimos pruebas automáticas inmediatamente mientras probamos la tarea en la misma rama con el desarrollador, por lo que es más importante para nosotros analizar la cobertura aquí y ahora. Después de que una tarea ingresa a main, ya está cubierta por pruebas automáticas;
Análisis de métodos y campos obsoletos: en la herramienta herramienta-de-cobertura-de-pruebas Es posible realizar un seguimiento de los métodos y campos que están marcados como obsoletos. Esto ayuda a eliminar o actualizar rápidamente las pruebas automáticas que verifican la funcionalidad obsoleta;
Evaluación y planificación de coberturas para nuevas funcionalidades. Cuando se trabaja con protocontratos, por regla general, los analistas de sistemas desarrollan los propios contratos antes de transferir la tarea al desarrollo. En consecuencia, antes de escribir pruebas automáticas, ya puede estimar la cantidad de trabajo para escribir pruebas automáticas utilizando contratos existentes.
Lo más probable es que haya muchas más formas de poner en práctica la herramienta; aquí es necesario basarse en equipos, procesos, requisitos y recursos específicos.
Conclusión
una herramienta herramienta-de-cobertura-de-pruebas resultó ser muy útil en mi equipo, ayudándome no solo a adoptar un enfoque consciente al escribir pruebas automáticas, sino también a evaluar objetivamente la cobertura del servicio. Le permite identificar lagunas en la cobertura incluso en la etapa de redacción de pruebas automáticas para nuevas funciones y, en consecuencia, reducir la probabilidad de errores, lo que en última instancia mejora la calidad del producto. Vale la pena señalar que la herramienta en sí no reduce directamente la probabilidad de errores, pero nos abre la posibilidad/opción de detectar lagunas a tiempo y completar las pruebas automáticas necesarias.
Para mí, una de las principales ventajas de la herramienta es su total automatización, que fue uno de los principales requisitos durante su desarrollo. Por otro lado, la herramienta no permite profundizar más que en los contratos, es decir, en la lógica empresarial del propio servicio. Para evaluar la lógica empresarial, por regla general, se crean tablas que describen una funcionalidad específica y un porcentaje de cobertura, y se realiza una correlación con casos de prueba. Este enfoque con tablas es difícil de automatizar, por lo que llevará mucho tiempo mantenerlo actualizado.
recomiendo probarlo herramienta-cobertura-pruebas en su proyecto si está trabajando con el protocolo gRPC. La herramienta está completamente lista para funcionar desde el primer momento y estoy seguro de que no te decepcionará, al menos es una experiencia muy interesante y útil.
Puedes encontrar todo el código fuente de la herramienta en mi GitHub:
