Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/marchena96/Paradigma-lab1/llms.txt

Use this file to discover all available pages before exploring further.

All three integration tests run against an in-memory SQLite database that is created and torn down automatically by the test fixture — no PostgreSQL credentials, no Supabase project, and no running API instance are needed. Anyone who clones the repository can execute the full suite immediately after restoring packages.

​
Quick run

From the repository root, restore, build, and run all tests in one line: 
dotnet restore && dotnet build && dotnet test --logger xunit --results-directory ./reports/
The --logger xunit flag writes an XML report compatible with most CI test dashboards. The --results-directory flag controls where that file lands.

​
Step-by-step

1

Navigate to the repository root

All dotnet commands below should be run from the directory that contains HackerRank1.sln:
cd Paradigma-lab1
2

Restore NuGet packages

Downloads all declared dependencies for both the API project and the test project:
dotnet restore
3

Build the solution

Compiles both HackerRank1 (the API) and LibraryService.Integration.Test:
dotnet build
The build should complete with 0 errors. A small number of nullable-reference warnings (CS8618, CS8603, CS8625) are cosmetic and do not affect correctness.
4

Run all tests

Executes every [Fact] method discovered in the solution:
dotnet test
5

(Optional) Run only the integration test project

If the solution grows additional test projects in the future, you can target just the integration tests:
dotnet test LibraryService.Integration.Test/LibraryService.Integration.Test.csproj

​
Expected output

A successful run reports all three tests as passing. The xUnit console output looks similar to the following: 
Test run for LibraryService.Integration.Test.dll (.NETCoreApp,Version=v8.0)
Microsoft (R) Test Execution Command Line Tool Version 17.6.3

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.

Passed!  - Failed:     0, Passed:     3, Skipped:     0, Total:     3
  ✓ LibraryService.Tests.IntegrationTests.TestAddBook_Ok_GetBook_NotFound
  ✓ LibraryService.Tests.IntegrationTests.TestGetBooks_Ok_NotFound
  ✓ LibraryService.Tests.IntegrationTests.TestDeleteLibrary
Test nameWhat it verifies
TestAddBook_Ok_GetBook_NotFoundPOST book → 201 for existing library; 404 for non-existent library
TestGetBooks_Ok_NotFoundGET books → 200 with correct count; 404 for non-existent library
TestDeleteLibraryDELETE library → 204; follow-up GET → 404; repeat DELETE → 404

​
Test isolation

Each instantiation of the IntegrationTests class gets its own WebApplicationFactory<Program> and its own LibraryContext backed by a fresh DataSource=:memory: SQLite connection. Because SQLite in-memory databases are scoped to a single open connection, two test instances can never share rows, even when running in parallel. The ChangeTracker is also cleared after each seed operation so that EF Core does not cache entity state across test steps. As a result, every [Fact] begins with an empty database that is populated only by its own seed calls.

​
CI/CD

No environment variables or secrets are required to run the test suite. The live PostgreSQL/Supabase database is completely replaced by SQLite in-memory inside the WebApplicationFactory, so a bare dotnet test is all any CI runner needs: 
# Example GitHub Actions step
- name: Run integration tests
  run: dotnet test --logger "trx;LogFileName=results.trx" --results-directory ./reports/
The ConnectionStrings:DefaultConnection secret (used by the live app) is not read during test execution and does not need to be injected into the CI environment.
If you have the live API running (dotnet run --project HackerRank1) in another terminal when you try to build, stop it first. The .exe produced by the previous build is locked by the running process, and MSBuild will fail with errors MSB3027/MSB3021 (“Could not copy … because it is being used by another process”).
To run a single test by name without executing the entire suite, use the --filter flag:
dotnet test --filter "FullyQualifiedName~TestDeleteLibrary"
Replace TestDeleteLibrary with any of the three test method names to isolate that one case.

Build docs developers (and LLMs) love

Get started for freeTalk to us