Organizing a C# Project

C# does not require every class to live in a same-named file, but one focused public type per file is a useful convention. The .csproj project file tells the .NET SDK the target framework, compiler settings, package references, and which files form one build output called an assembly.

A solution can group several related projects, such as an application, a reusable domain library, and a test project. Do not split a small learning program into many assemblies immediately. Add a project boundary when independent deployment, dependencies, reuse, or test organization justify it.

A namespace qualifies type names and avoids collisions: StudyTracker.Domain.Session differs from AnotherProduct.Session. Folder structure often mirrors namespaces because that helps navigation, but the compiler does not require the paths to match.

using imports a namespace for shorter references; it does not copy code or install a library. A package reference brings an external compiled dependency into the project. These are different operations even though both can lead to new type names becoming available.

Console.ReadLine, file paths, and display colors are delivery details. The rule that a study session must have positive minutes is domain logic. Keeping rules in focused classes or methods lets a later web interface reuse them and lets tests call them without simulating a terminal.

A practical small structure might have Program coordinate the use case, Domain types enforce rules, and a file repository handle persistence. Do not create layers whose only work is passing the same values onward. Every boundary should make a dependency, policy, or ownership decision clearer.

StudyTracker/
StudyTracker.csproj
Program.cs
Domain/
  StudySession.cs
  StudyLog.cs
Storage/
  FileStudySessionRepository.cs
Tests/
  StudyTracker.Tests.csproj

NuGet packages provide reusable libraries. Add one only after checking ownership, maintenance, license, security posture, target-framework compatibility, and whether the standard library already solves the problem. Pin and review dependency updates rather than pasting package commands from old tutorials blindly.

Configuration that varies by environment—paths, service endpoints, feature settings—should not be hardcoded with secrets in source control. Tests should target decisions, calculations, and invariants. A method such as CalculateShipping is easier to test than a Main method that reads input and prints inside the calculation.

A unit test calls a small piece of code, supplies a controlled input, and checks one observable result. It should fail for a useful reason when the rule is wrong. Start with a boundary because boundaries concentrate mistakes: for free shipping at 5000 cents, test just below it, exactly at it, and above it.

Keep the calculation outside Program so the test can call it without simulating console input. The following commands create a class library and an xUnit test project, connect the test project to the production project, and run the suite. Run them from a new empty directory. The solution filename can vary with the installed SDK; the dotnet sln add commands work against the solution created in that directory.

dotnet new sln --name Shipping
dotnet new classlib --name Shipping.Domain
dotnet new xunit --name Shipping.Domain.Tests
dotnet sln add Shipping.Domain/Shipping.Domain.csproj
dotnet sln add Shipping.Domain.Tests/Shipping.Domain.Tests.csproj
dotnet add Shipping.Domain.Tests/Shipping.Domain.Tests.csproj reference Shipping.Domain/Shipping.Domain.csproj
dotnet test

The theory below expresses three boundary examples without duplicating the test body. First make the test fail by returning the wrong amount, then implement the smallest rule that makes every example pass. A red-green-refactor loop proves that the test can detect failure before you trust its success.

namespace Shipping.Domain;

public static class ShippingCalculator
{
  public static int CalculateShippingInCents(int subtotalInCents) =>
      subtotalInCents >= 5000 ? 0 : 599;
}

Place that class in Shipping.Domain/ShippingCalculator.cs. Then replace the generated test file with this test class:

using Shipping.Domain;
using Xunit;

public class ShippingCalculatorTests
{
  [Theory]
  [InlineData(4999, 599)]
  [InlineData(5000, 0)]
  [InlineData(5001, 0)]
  public void Calculates_shipping_at_free_shipping_boundary(
      int subtotalInCents,
      int expectedShippingInCents)
  {
      int actual = ShippingCalculator.CalculateShippingInCents(subtotalInCents);

      Assert.Equal(expectedShippingInCents, actual);
  }
}

Test behavior that callers depend on: returned values, state changes, and deliberate exceptions. Avoid asserting private methods or the exact internal steps of an algorithm. Those tests resist safe refactoring and confuse implementation with the contract.