The BackupData project currently has unit tests mixed in with production code. BackupJobTests.cs sits alongside BackupJob.cs, and the .csproj includes test dependencies (NUnit, Moq, FluentAssertions) that get bundled into the production build.
This causes a few problems:
- The deployed container includes test assemblies and dependencies it doesn't need
- Test code can accidentally reference internal implementation details without realizing it
- Running
dotnet test and dotnet run operate on the same project, which gets confusing
Proposed structure:
tools/blobstorage-backupdata/
├── src/
│ └── BackupData/
│ ├── BackupData.csproj
│ ├── Program.cs
│ ├── BackupJob.cs
│ ├── Log.cs
│ └── JObjectExtensions.cs
├── tests/
│ └── BackupData.Tests/
│ ├── BackupData.Tests.csproj
│ ├── BackupJobTests.cs
│ └── (test helpers)
└── BackupData.sln
The test project would reference the main project and contain all the NUnit/Moq/FluentAssertions dependencies.
The
BackupDataproject currently has unit tests mixed in with production code.BackupJobTests.cssits alongsideBackupJob.cs, and the.csprojincludes test dependencies (NUnit, Moq, FluentAssertions) that get bundled into the production build.This causes a few problems:
dotnet testanddotnet runoperate on the same project, which gets confusingProposed structure:
The test project would reference the main project and contain all the NUnit/Moq/FluentAssertions dependencies.