Skip to content

Project · C# and .NET

Project: a tested GST invoice library

Projectexpert· about 7 hours· 7 steps

The brief

Build Invoicing.Core, a small class library that works out GST per line, invoice totals and the rupee round-off, and payment due dates. Every rule is proved by xUnit tests: facts, a theory over the GST slabs, a test written before the code (red, then green), and a fake clock. Finally you pack it as a NuGet package.

Why it matters

Billing rules are where companies cannot afford mistakes, so .NET teams keep them in a separate library with a thick layer of unit tests, and share it between their web API, desktop app and reports as a NuGet package. Interviewers for .NET roles often ask you to write exactly these tests, and to explain why time must be injected.

Skills you practise

  • solutions and project references
  • class libraries
  • xUnit [Fact] and [Theory]
  • Arrange, Act, Assert
  • red-green testing
  • interfaces as test doubles
  • dotnet pack

You need

  • .NET 8 SDK or newer
  • A code editor (VS Code with the C# Dev Kit, Visual Studio or Rider)

What you will have at the end

The Invoicing solution: Invoicing.Core (GST per line, invoice totals with round-off, payment terms with an injected clock), Invoicing.Tests with fifteen passing tests, and Invoicing.Core.1.1.0.nupkg. Push it to GitHub with a README that lists the rules and how to run the tests.

How it is marked (rubric, 100 points)
Rules proved by testsAll fifteen tests pass, including the half-paisa theory row, the half-rupee round-off and the due-date edge.35
Good testsArrange-Act-Assert, expected value first, one behaviour per test, names like Method_Scenario_Expected, no DateTime.Now.30
Library designInvoice reuses Gst.LineGst; time comes through IClock; the library has no console or file code.20
PackagingVersion 1.1.0 with Authors and Description; bin, obj and packages are not committed.15

0/7 steps done

Step 1 of 7

A solution with a library and a test project

The Invoicing solution holds Invoicing.Core and Invoicing.Tests, the tests reference the library, and dotnet test runs the template's one test.

Real code is split into projects grouped by a solution. The rules go in a class library (no Main, no console), and the tests go in their own xUnit project that references it. dotnet sln add puts both in the solution, so one dotnet test from the solution folder builds and tests everything. Newer SDKs create Invoicing.slnx instead of Invoicing.sln; both work the same way.

Run this on your machine, then paste the output below
$ mkdir Invoicing cd Invoicing dotnet new sln -n Invoicing dotnet new classlib -o Invoicing.Core dotnet new xunit -o Invoicing.Tests dotnet sln add Invoicing.Core Invoicing.Tests dotnet add Invoicing.Tests reference Invoicing.Core dotnet test

Also check yourself

Your notes: Gst.cs, Invoice.cs, PaymentTerms.cs, GstTests.cs, InvoiceTests.cs

Write down each command you ran. It goes into your project summary.