Skip to content

Development Setup

This page covers the development workflow, build commands, and testing setup for contributors.

Build Commands

Command Description
dotnet watch --project src/TechStrat.Api Run with hot reload (recommended for development)
dotnet build TechStrat.slnx Build all projects
dotnet test TechStrat.slnx Run all tests (requires Docker)
dotnet test tests/TechStrat.Core.Tests Run unit tests only (no Docker needed)

Development Server

Always use dotnet watch during development rather than dotnet run:

dotnet watch --project src/TechStrat.Api

Why not dotnet build separately?

The Blazor WASM build pipeline generates fingerprinted asset filenames (e.g., dotnet.native.87vtjj.wasm). The server reads the fingerprint manifest at startup. Running dotnet build separately while the server is running produces new fingerprints that the running server does not know about, causing 404 errors for static assets. dotnet watch handles this correctly by restarting the server when needed.

Check for existing instances

Before starting the server, check if an instance is already running on port 5001: 

netstat -ano | findstr :5001   # Windows
lsof -i :5001                  # macOS/Linux

Database Management

Reset the database

To completely reset the database (destroy all data and recreate):

docker compose -f docker/docker-compose.yml down -v
docker compose -f docker/docker-compose.yml up -d

Create a migration

When you change EF Core entity models or the DbContext, create a new migration:

dotnet ef migrations add <MigrationName> \
  --project src/TechStrat.Infrastructure \
  --startup-project src/TechStrat.Api \
  --output-dir Persistence/Migrations

Migrations are auto-applied in development mode when the server starts. See Migrations for detailed guidance.

Running Tests

Unit tests (fast, no dependencies)

dotnet test tests/TechStrat.Core.Tests

These tests cover the domain logic — the event processor, model operations, and business rules. They require no database or Docker.

Integration tests (requires Docker)

dotnet test tests/TechStrat.Api.Tests
dotnet test tests/TechStrat.Infrastructure.Tests

Integration tests use Testcontainers to spin up a PostgreSQL instance automatically. Docker must be running.

All tests

dotnet test TechStrat.slnx

Test counts

The project currently has approximately 200+ tests across all three test projects:

  • Core tests — ~164 unit tests covering event processing logic
  • API tests — ~36 integration tests covering endpoints and auth
  • Infrastructure tests — ~37 persistence tests covering repositories

Project Structure

The solution is organized into clearly separated layers:

src/
  TechStrat.Core/             Pure domain (zero dependencies)
  TechStrat.Infrastructure/   PostgreSQL persistence (depends on Core)
  TechStrat.Shared/           DTOs shared between API and Blazor
  TechStrat.Api/              ASP.NET Core host (depends on all src projects)
  TechStrat.UI/               Shared Razor components
  TechStrat.StrategySite/     Blazor WASM - Strategy Site
  TechStrat.AdminSite/        Blazor WASM - Admin Site

tests/
  TechStrat.Core.Tests/            Unit tests
  TechStrat.Api.Tests/             Integration tests
  TechStrat.Infrastructure.Tests/  Persistence tests

docker/
  docker-compose.yml         PostgreSQL dev instance

Dependency rules

The layering follows strict dependency rules:

graph TD
    A[TechStrat.Core] -->|no dependencies| A
    B[TechStrat.Shared] -->|no dependencies| B
    C[TechStrat.Infrastructure] --> A
    D[TechStrat.UI] --> B
    E[TechStrat.StrategySite] --> D
    E --> B
    F[TechStrat.AdminSite] --> D
    F --> B
    G[TechStrat.Api] --> C
    G --> B
    G --> E
    G --> F
  • Core has zero external dependencies — pure domain logic only
  • Infrastructure depends only on Core
  • Shared has no project dependencies (DTOs only)
  • UI depends only on Shared
  • Site projects depend on UI and Shared
  • Api is the composition root that references everything

Next Steps