A test-driven .NET backend for analysing Git repositories, built as a practical learning project focused on C#, ASP.NET Core, architecture, and automated testing.
GitDashboard is a web application for analysing local Git repositories and public GitHub repositories. A React frontend displays repository statistics returned by an ASP.NET Core API.
The project is primarily a practical learning and portfolio project, focused on developing deeper experience with C#, .NET, ASP.NET Core, backend architecture, automated testing, and Test-Driven Development (TDD).
The application is developed incrementally, with tests used to drive implementation and design decisions.
Try the hosted application. The app is containerised with Docker and served on Render.
The main goal is to use a real, evolving application to develop practical backend engineering skills.
Areas being explored include:
The project is intentionally designed so that architectural decisions emerge from real requirements rather than attempting to design the entire system in advance.
The application currently supports analysing local Git repositories and public GitHub repositories. The React frontend is served alongside the API.
The API exposes:
GET /api/analyse
/api/analyse?path=/path/to/repository
/api/analyse?owner=username&name=repository
The application retrieves all commits from the selected repository source (using pagination for GitHub) and calculates repository statistics.
Currently calculated statistics include:
Repository access is separated from repository analysis through a repository-source abstraction.
HTTP Request
│
▼
RepositoryAnalysisService
│
▼
IRepositorySourceResolver
│
▼
RepositorySourceResolver
│
├── LocalRepositorySource
│
└── GitHubRepositorySource
│
▼
List<Commit>
│
▼
StatisticsService
│
▼
RepositoryStats
│
▼
HTTP Response
This separation allows additional repository providers to be introduced without coupling the analysis logic to a particular source.
Repository types are represented explicitly, currently including:
LocalRepositoryReferenceGitHubRepositoryReferenceThe RepositorySourceResolver selects the appropriate IRepositorySource based on the repository reference.
GitHub repositories are accessed through GitHub's REST API using an injected HttpClient.
The GitHub integration includes:
HttpClient configurationGitHub:Token setting (for example, the GitHub__Token environment variable)GitHub API failures are distinguished from invalid repositories. General upstream API failures return 502 Bad Gateway; detected primary rate limits return 429 Too Many Requests and include a Retry-After header when GitHub provides a reset time. Without a token, requests use GitHub's unauthenticated rate limit.
Testing is a central part of the development process.
The project uses xUnit and contains both unit and integration tests.
Tests currently cover areas including:
External HTTP calls are isolated from unit tests using fake HTTP handlers, allowing success and failure scenarios to be tested deterministically without depending on the availability of GitHub.
The test suite includes unit and integration tests and runs in the GitHub Actions build workflow.
The project follows a Test-Driven Development workflow:
Define behaviour
↓
Write a failing test
↓
Implement the smallest change
↓
Make the test pass
↓
Run the full test suite
↓
Refactor where appropriate
↓
Repeat
This approach is being used not only to verify correctness, but also to help drive the architecture.
For example, support for GitHub repositories led to the introduction of:
IRepositorySourceIRepositorySourceResolverEach of these was introduced as the application's requirements evolved.
This project is being developed with AI-assisted technical mentoring.
AI is being used as a development partner to:
The intention is not to generate the application wholesale, but to use AI as a learning aid while implementing and understanding the code incrementally.
A key objective of the project is therefore:
To understand the design and reasoning behind the code, rather than simply producing working code.
The commit history reflects the incremental nature of the project and the progression of its architecture.
The project is still actively evolving.
Future analysis features may include:
Planned improvements include:
As the application grows, the API and application boundaries will be reviewed.
In particular, repository-reference parsing currently happens at the HTTP endpoint. This may eventually move into a dedicated application-layer component as the number of supported repository types grows.
Testing will continue to evolve alongside the application, with an emphasis on:
By the end of the project, I want to be able to demonstrate practical experience with:
The GitDashboard application is the vehicle for that learning; the broader objective is to develop a stronger understanding of professional backend development and test-driven engineering practices.