save cli
v0.3.10
Guardar es un marco de prueba de línea de comandos para todo uso que se puede utilizar para probar herramientas que funcionan con código, como analizadores estáticos y compiladores. Es una aplicación totalmente nativa, que no requiere necesidad de instalar ningún SDK.
La verificación y evaluación del análisis estático (SAVE) es un ecosistema (ver también Save-Cloud) diseñado para la evaluación, prueba y certificación de analizadores estáticos, compiladores o cualquier otra herramienta de software. En lugar de desarrollar su propio marco de prueba, puede utilizar SAVE como una aplicación de prueba de línea de comandos. El único requisito es preparar los recursos de prueba en el formato apropiado.
¡Necesitamos su ayuda! Nos alegrará si usa, prueba o contribuye a este proyecto. En caso de que no tenga mucho tiempo para esto, ¡al menos danos una estrella para atraer a otros contribuyentes! ¡Gracias! ?
- Mi herramienta de análisis de código procesa archivos secuencialmente, uno por uno ;
- Produce advertencias y las lleva a stdout ;
- Quiero comparar las advertencias reales con las advertencias esperadas que se especifican dentro del código de recursos de prueba .
- También tengo una herramienta de análisis de código, pero procesa todo el proyecto a la vez y es consciente de todas las relaciones con el código.
- Produce advertencias y las lleva a stdout ;
- Quiero comparar las advertencias reales con las advertencias esperadas que se especifican dentro del código de recursos de prueba .
- Mi herramienta manipula el código original, por ejemplo, al fijarlo automáticamente;
- Me gustaría verificar cómo mi herramienta corrige el código comparándolo con el resultado esperado;
- Además, los compiladores pueden utilizar la generación de código , la transición de la fuente original
- Código a representación intermedia (IR), otro lenguaje de programación o incluso ensamblaje.
- No quiero especificar mis advertencias esperadas en el código;
- Prefiero usar un archivo separado en SARIF o cualquier otro formato.
save "/my/path/to/tests" Asegúrese de que el directorio tests contenga el archivo de configuración save.toml .
Para depurar guardar la ejecución, puede usar el siguiente argumento: --log=TYPE , donde TYPE puede ser uno de los siguientes:
all : registro integral que incluye toda la información de la ejecución de guardado, aún más detallada que la depuración (similar a un rastro).debug : muestra resultados, advertencias e información de depuración.warnings : muestra resultados y advertencias críticas.results_only : muestra solo los resultados. 
Aquí hay una lista de complementos estándar:
Si desea que se operen múltiples complementos en su directorio utilizando los mismos archivos de prueba (recursos), simplemente agregue todos a la configuración save.toml :
[general]
...
[fix]
...
[warn]
...
[other plugin]
...
Puedes leer más sobre el warn plugin aquí
Guardar tiene una interfaz de línea de comandos que le permite ejecutar tanto el marco como su ejecutable. Su tarea principal es configurar la salida de su analizador estático para que Guardar pueda verificar si el error apropiado se marcó en la línea correcta del código de prueba.
Para garantizar que la advertencia sea precisa para Guardar, su analizador estático debe generar el resultado, ya sea a Stderr/STDOut o a un archivo de registro designado (por ejemplo, en formato SARIF).
Puede configurar el comportamiento general de Save utilizando argumentos de línea de comandos o utilizando un archivo de configuración llamado save.properties . Este archivo debe ubicarse en el mismo directorio que la configuración de la prueba raíz, save.toml .
Para obtener una lista completa de opciones que se pueden pasar para guardar a través de la línea de comandos o el archivo save.properties , consulte la tabla de opciones o ejecute el comando save --help . Tenga en cuenta que las opciones con opciones son sensibles a los estuches.
El marco de guardado detectará automáticamente sus pruebas, ejecutará su analizador en ellas, calculará la tasa de aprobación y devuelve los resultados de la prueba en el formato esperado.
Para habilitar Guardar para detectar sus suites de prueba, debe colocar un archivo save.toml en cada directorio que contenga suites de prueba . Es importante tener en cuenta que estos archivos de configuración heredan las configuraciones de los directorios principales.
Aunque la mayoría de los campos se pueden dejar indefinidos en niveles más bajos y pueden heredar valores de los niveles superiores, debe ser cauteloso. Algunos campos en la sección [general] son obligatorios para la ejecución, por lo que debe especificarlos en al menos un archivo de configuración en la cadena de herencia para las pruebas que deben ejecutarse. Verifique qué campos son obligatorios.
Por ejemplo, con la siguiente jerarquía del directorio:
| A
| save.toml
| B
| save.toml
save.toml en el Directorio B heredará la configuración y las propiedades del Directorio A.
Tenga en cuenta que Save detectará todos los archivos con el Postfix 'Prueba' y utilizará automáticamente configuraciones desde el archivo save.toml presente en el mismo directorio (o heredado de los padres). Las pruebas se nombran de acuerdo con el nombre del recurso del archivo de prueba, excluyendo el sufijo de 'prueba'. Si Save detecta un archivo con el postfix 'Prueba' en los recursos de prueba y no puede localizar ninguna configuración save.toml en la jerarquía de directorio , lanzará un error.
Por ejemplo, el escenario a continuación no es válido y activará un error, ya que el marco de guardado no puede localizar el archivo de configuración save.toml :
| A
| B
| myTest.java
Como se mencionó anteriormente, el save.toml es esencial para configurar pruebas. Idealmente , debe haber un archivo de configuración para cada directorio que contenga pruebas, estableciendo una relación de uno a muchos. Nos referimos a estos directorios como test suites .
La justificación detrás de tener un solo archivo de configuración para un conjunto de pruebas es evitar configuraciones redundantes dentro del mismo conjunto de pruebas.
La configuración Guardar utiliza el formato TomL alimentado por el proyecto KTOML. Como se mencionó anteriormente, save.toml se puede heredar de la jerarquía de directorio (directorios de padres).
El archivo de configuración contiene una tabla [general] y una tabla [plugins] . Para obtener más información sobre los complementos, consulte la sección de complementos.
En esta sección, proporcionaremos información solo sobre la tabla [general] , que se puede usar en todos los complementos.
[general]
# Your custom tags that will be used to detect groups of tests (required)
tags = ["parsing", "null-pointer", "etc"]
# Custom free text that describes the test suite (required)
description = "My suite description"
# Simple suite name (required)
suiteName = "DocsCheck", "CaseCheck", "NpeTests", "etc"
# Execution command (required at least once in the configuration hierarchy)
# By the default these binaries should be in the same directory of where SAVE is run
# or should have full or relational path (root - is the directory with save executable)
execCmd="./ktlint -R diktat-0.4.2.jar"
# Excluded tests in the suite (optional). Here, you can list the names of excluded tests, separated by commas. By default, no tests are excluded.
# To exclude tests, use the relative path to the root of the test project (to the root directory of `save.toml`)
excludedTests = ["warn/chapter1/GarbageTest.kt", "warn/otherDir/NewTest.kt", "etc"]
# Command execution time for one test (in milliseconds)
timeOutMillis = 10000
# Language for tests
language = "Kotlin"
A veces, es posible que desee ejecutar solo un conjunto específico de pruebas en lugar de ejecutar todas las pruebas en una configuración save.toml particular. Para lograr esto, pase la ruta relativa al archivo de prueba después de todas las opciones de configuración (root - IS Directory con Guardar binario):
$ save [options] /path/to/tests/Test1También puede proporcionar una lista de rutas relativas para probar archivos (separados por espacios):
$ save [options] /path/to/tests/Test1 /path/to/tests/Test2 Guardar detectará automáticamente el archivo save.toml más cercano y usará la configuración desde él.
Note: En Windows, recuerde usar una doble barra de retroceso \ como el separador de ruta.
Guardar admite varios formatos para la salida del informe de prueba:
PLAIN : una tabla similar a una marca que muestra todos los resultados de las pruebas.PLAIN_FAILED : similar a PLAIN , pero solo muestra pruebas fallidas.JSON : Representación estructurada del resultado de la ejecución. El formato deseado se puede seleccionar utilizando la opción --report-type=PLAIN .
El uso de analizadores estáticos es una parte integral del proceso de desarrollo para cada producto de software. Si bien los desarrolladores de software pueden escribir varias pruebas y lograr una buena cobertura de pruebas, el error humano sigue siendo inevitable. Dichos errores pueden dar lugar a pérdidas financieras significativas para las empresas. El análisis del programa estático ayuda a identificar y rectificar errores y problemas que podrían no ser detectables solo con validaciones de compiladores.
El análisis estático viene en varias formas y tiene diferentes propósitos. Puede implicar un análisis simple utilizando un AST (árbol de sintaxis abstracto) o profundizar en procedimientos más complejos como CFA (análisis de flujo de control), análisis interprocedural o análisis sensible al contexto. Los analizadores estáticos pueden evaluar el estilo del código, identificar posibles problemas de tiempo de ejecución en la lógica de la aplicación, detectar los olores de código y sugerir las mejores prácticas. Sin embargo, sigue habiendo una falta de claridad sobre las funciones centrales de los analizadores estáticos. ¿Cómo se puede cuantificar su eficacia? ¿Qué criterios determinan su aceptación? ¿Qué funcionalidades son esenciales para los desarrolladores que crean un nuevo analizador? A pesar de los años de desarrollo del analizador estático, estas preguntas siguen siendo en gran medida sin respuesta.
Al inicio de su viaje de desarrollo, cada creador de un analizador estático comienza con la identificación de los tipos de problemas que se dirigirá a su herramienta. Esto a menudo requiere una búsqueda de listas existentes de posibles problemas o paquetes de prueba que puedan guiar el proceso de desarrollo, particularmente si sigue un enfoque de TDD (desarrollo basado en pruebas). Mientras que otros dominios en la programación del sistema han establecido puntos de referencia y conjuntos de pruebas, como los puntos de referencia Spec.org utilizados a nivel mundial para evaluar varios componentes de software y hardware, no existen tales estándares para identificar problemas en lenguajes de programación populares. MISRA ha establecido pautas para la codificación en C/C ++, no hay equivalentes para idiomas ampliamente utilizados como Python y JVM-Lenguages. Hay suites de prueba disponibles en NIST, pero su marco y ecosistema son algo restrictivos.
Dado este escenario, los desarrolladores a menudo se encuentran recreando mecanismos para el análisis estático o el desarrollo de nuevos marcos de prueba, lo que lleva a un trabajo repetitivo. Algunos podrían optar por las pautas existentes, como el estilo del código de Google o las reglas PMD, pero independientemente del enfoque, se dedica invariablemente tiempo a conceptualizar, escribir y depurar pruebas.
El proyecto utiliza Gradle como su sistema de compilación y se puede construir utilizando el comando ./gradlew build .
Para compilar artefactos nativos, debe instalar los requisitos previos como se describe en la documentación Kotlin/Nativa.
Para acceder a las dependencias alojadas en el registro del paquete GitHub, agregue lo siguiente a gradle.properties o ~/.gradle/gradle.properties :
gprUser =<GH username>
gprKey =<GH personal access token> Se puede generar un token de acceso personal en https://github.com/settings/tokens/new. Asegúrese de que el token tenga un alcance que incluya read:packages .
Debido al código generado, debe ejecutar la compilación una vez para importar correctamente el proyecto en un IDE con importaciones resueltas.
