Skip to content

Engineering Assessment: DebugProbe.AspNetCore #39

Description

@gimi555

Hi @georgidhristov
This is what I can see on my side.

Summary
The entire structure is straightforward. One library, one simple app, clear top-level folders.
But the project lacks automated testing, and a few process gaps will become friction as it scales.

Findings

1. No test coverage
The solution has DebugProbe.AspNetCore and DebugProbe.SampleApi, but no test project. CONTRIBUTING.md points to manual verification through the sample app.
For middleware handling exceptions, body capture, and response rendering, this is a risk. Unit and integration tests would cover core paths. Without them, any refactor risks regressions.

2. CI scope is limited
The workflow restores and builds DebugProbe.AspNetCore.csproj only. It does not build the full solution or run the sample app. Passing builds confirm that the library compiles. They confirm nothing else.

PLUS: Commit and PR conventions are mixed.
CONTRIBUTING.md defines branch naming, but not commit or PR title format.
It slows down code review and, most importantly, it gives the impression of non-senior collaboration.
History blends conventional commits (e.g., feat:, fix:) with loose subjects. PR titles vary too.

https://www.conventionalcommits.org/en/v1.0.0/#specification

Hope it helps you.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions