e203034228
The current code base regarding API entrypoint is not testable as it directly connects to Gitea when creating the API endpoints. This prevented my from writing tests in the past for that part. As the SonarQube quality gate broke due to changes in the API entrypoint logic, tests are now required to satisfy the quality gate. Therefore, the instantiation of the API handlers is now decoupled from building the bot API endpoints and follows the same interface wrapper strategy as used for the Gitea API client. This makes it testable. Now, tests are written for the most parts of the API entrypoint. I've also noticed that there was much overhead within the tests for a non-implemented function `fetchDetails`. So I dropped that function for now. Signed-off-by: Steven Kriegler <sk.bunsenbrenner@gmail.com> Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: https://codeberg.org/justusbunsi/gitea-sonarqube-bot/pulls/22
19 lines
506 B
Properties
19 lines
506 B
Properties
sonar.sourceEncoding=UTF-8
|
|
|
|
sonar.host.url=https://sonarcloud.io
|
|
sonar.organization=justusbunsi
|
|
sonar.projectKey=gitea-sonarqube-bot
|
|
sonar.projectName=Gitea SonarQube Bot
|
|
|
|
sonar.sources=.
|
|
sonar.exclusions=**/*_test.go,contrib/**,docker/**,docs/**,helm/**
|
|
|
|
sonar.tests=.
|
|
sonar.test.inclusions=**/*_test.go
|
|
|
|
# Entrypoint of the application and not properly testable
|
|
sonar.coverage.exclusions=cmd/gitea-sonarqube-bot/main.go
|
|
|
|
sonar.go.tests.reportPaths=test-report.out
|
|
sonar.go.coverage.reportPaths=cover.out
|