Skip to content

Engineering Assessment: DebugProbe.AspNetCore #39

@gimi555

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.

Metadata

Metadata

Labels

documentationImprovements or additions to documentationenhancementNew feature or requesttestingAutomated tests, test coverage, and validation improvements

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions