SonarCloud doesn't detect tests for routes.js

[uo289321]

Arquisoft/wiq_es05b#167
In the develop branch, after doing the tests for all the routes.js, SonarCloud doesn't link the tests with the files, and it says that there's 0% coverage, even after changing the names in case it didn't pick them up because of that.

In local, if you do "npm test -- --coverage", it says there's a percentage.

(Jordi is the question service)

[pglez82]

I have accessed your sonarcloud and I get different results. The ones that I get are very similar to those showed by jest:

I am checking the main branch coverage. Maybe are you checking another branch in SonarCloud?

[uo289321]

Sorry I didn't specify, the coverage needs to be checked on the branch develop, that it's the one with the updated tests.

[algarfer]

Hi Pablo
We have just performed a merge to master with several tests and new functionality that was not fully tested.

The current report of sonarcloud for the master branch displays 66.3% coverage for the new code and 66.7% for the overall code:

If we have a look at the sonarcloud coverage report there are some files with low coverage like these:

And this does not meet the coverage reported by jest on the actions log since we have approximately 83.16% (supposing the overall coverage is the mean of the tests coverage):

Do you know if sonarcloud is misinterpreting the results or how we can fix this problem?

[pglez82]

Evidentemente hay algún problema, que a simple vista no estoy viendo. Donde realmente hay que mirar es en el log de la action que está corriendo los tests antes de subir el informe, pero ahí tampoco veo nada raro porque la cobertura que está generando está bien (la que os sale a vosotros en local).

Lo único que se me ocurre es subir el coverage desde local, sin pasar por actions, para intentar ver el problema que hay.

Para esto deberíais de correr en local los tests y generar en local el reporte de cobertura. A continuación, necesitareis el cliente de sonar cloud en linea de comando.

https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/scanners/sonarscanner/

Alguna vez que me ha pasado esto que os ha pasado a vosotros he acabado encontrando el fallo gracias a este cliente.

Ya me decís si os sirve para algo.

[pglez82]

He probado a bajar el repositorio. Poniendo esto, he quitado los errores de los paths:

sonar.sources=users/authservice,users/userservice,gatewayservice,webapp/src,userhistory,jordi

Yo creo que se lia porque las rutas que hay en el lcov.info son relativas a el path en donde ejecutas los tests, que sería en este caso cada una de las carpetas generales (donde está el package.json).

Probad a poner esto a ver si cambia algo. Yo lo he probado (sin subir los resultados a sonarcloud) y ya solo quedan 2 warnings de ficheros con los paths mal (que es el que hablamos antes que está en el node modules y que habría que excluir).

En cuanto a la excepción de que no encuentra cierta linea en el código fuente, veo que me da para el archivo userRepository.js. He buscado en vuestro repositorio y veo que hay dos, en dos servicios diferentes (authService y userService). Puede ser (aunque no debería, que se esté liando). ¿Podéis probar a refactorizar y cambiar el nombre a uno de estos dos archivos?

Por último, ejecutando en local sonar-scanner --debug podéis ver muchísima información útil para depurar el problema. Podéis redireccionar toda la salida a un archivo y subirlo aquí para poder ver que pasa en caso de que todavía no funcione la cosa.

[algarfer]

Es correcto, habíamos cambiado los paths para hacer pruebas pero se nos paso volver a ponerlo como estaba, aun así ayer los tenia en local como mencionas.

Los warning por los archivos es fácil de quitar desde el workflow, yo los tengo borrados en local. Tambien es cierto que en el log menciona que hay varias inconsistencias en el reporte de cobertura:

En un rato pruebo a refactorizar los nombres de los archivos y te comento.

Y el sonar tambien lo estaba ejecutando con sonar.verbose=true en local. @augustocristian nos mencionó que lo dejemos activado en el workflow en Arquisoft/wiq_es05b#167 hasta que resolvamos el problema.

[pglez82]

Ejecutarlo en local con --debug como os dije anteriormente, no hace falta que lo hagáis en el actions. Ahí se ve todo. Podéis subir la traza aquí para verla.

[algarfer]

report.txt

Esta vez he modificado el nombre de los archivos y ha subido al 71% y parece que ya detecta bien los ficheros.

Aun asi los porcentajes no cuadran del todo con lo que reporta jest, teniendo algunos servicios entre un 1% o 2% menos hasta otros que tienen casi un 10% menos.

Aun así me esta detectando un fichero de python, el cual ya no es necesario por lo que iba a eliminarlo y volver a medirlo.

[pglez82]

Bueno ahora ya parece que va teniendo sentido la cosa. Quizás tengáis que ignorar algún fichero que no hace falta testear y subiendo un poco la cobertura de alguno por ahí que está bajo yo creo que podéis llegar al 80% sin mucho problema.

En cuanto que las diferencias de medida. Quizás no lo midan exactamente igual, no estoy seguro. Prueba a abrir el fichero en sonarcloud y ver que las lineas que te dice que no están siendo tocadas por los tests tienen sentido o no.