The GrindCore.net testing infrastructure is designed to validate high-performance compression and hashing operations across multiple .NET Target Framework Monikers (TFMs) and CPU architectures. The suite ensures parity between synchronous and asynchronous APIs, verifies compatibility with standard formats (like 7-Zip and System.IO.Compression), and monitors for native memory leaks.
The infrastructure is split into three primary projects, each serving a distinct role in the validation pipeline.
| Project | Purpose | Key Technologies |
|---|---|---|
GrindCore.Tests | Primary unit test suite covering all algorithms, edge cases, and utilities. | xUnit, XXHash64 validation |
GrindCore.Tests.Runtime | A standalone, reflection-based test runner used for environments where standard xUnit runners are unavailable or unstable. | Reflection, Activator, Manual GC |
StressLzma | A multi-threaded stress testing tool specifically for LZMA2 stability and performance. | Console App, CircularSequenceQueue |
Code Entity Mapping
The following diagram shows how the test projects interact with the core library and external validation logic.
Test System Relationship
Sources: tests/GrindCore.Tests/GrindCore.Tests.csproj45-47 tests/GrindCore.Tests.Runtime/Program.cs24-28
This is the main test assembly. It contains exhaustive tests for every supported algorithm, focusing on boundary conditions like empty streams, non-compressible data, and large payloads. It includes a CompressionStreamDotNetTests suite to ensure that GrindCore's GZip, ZLib, and Deflate implementations are compatible with System.IO.Compression.
CompressionStream and CompressionBlock behaviors across all levels. It specifically tests AsyncCompress_SmallData_MatchesSyncResults to ensure API parity tests/GrindCore.Tests/CompressionStreamAsyncTests.cs52-97For details, see GrindCore.Tests: Compression Tests and GrindCore.Tests: LZMA-Specific & Hash Tests.
Sources: tests/GrindCore.Tests/CompressionStreamDotNetTests.cs21-30 tests/GrindCore.Tests/CompressionStreamAsyncTests.cs42-51
A critical component of the testing infrastructure is the MemoryLeakTests suite. Because GrindCore relies heavily on native memory and P/Invoke, tests monitor for leaks while performing thousands of cycles to ensure IDisposable patterns correctly release native handles.
The suite also provides custom test streams in the GrindCore.Tests.Utility namespace:
TestDataStream: Generates repeatable pseudo-random data tests/GrindCore.Tests/CompressionStreamDotNetTests.cs72TestPseudoTextStream: Generates highly compressible text-like data tests/GrindCore.Tests/CompressionStreamDotNetTests.cs73TestNonCompressibleDataStream: Generates high-entropy data to test "expansion" scenarios.For details, see GrindCore.Tests: Memory Leak & Utility Tests.
Sources: tests/GrindCore.Tests/CompressionStreamDotNetTests.cs72-74 tests/GrindCore.Tests/CompressionStreamAsyncTests.cs33-40
The GrindCore.Tests.Runtime project is a specialized console application that acts as a manual test runner. It uses reflection in Program.Main to discover xUnit TheoryAttribute and InlineDataAttribute within the GrindCore.Tests assembly tests/GrindCore.Tests.Runtime/Program.cs32-47
This runner is particularly important for:
dotnet test runner might struggle.finally block, it performs a triple GC.Collect() and GC.WaitForPendingFinalizers() sequence between tests to ensure native resources are freed and to isolate memory usage per test tests/GrindCore.Tests.Runtime/Program.cs104-111For details, see GrindCore.Tests.Runtime: Reflection-Based Test Runner.
Sources: tests/GrindCore.Tests.Runtime/Program.cs11-123
The infrastructure extends beyond simple unit tests into integration and stress testing:
For details, see SharpCompress Integration Tests & StressLzma.
Since the unit tests require native binaries (GrindCore.dll, libGrindCore.so, or libGrindCore.dylib), the project files include a custom MSBuild target CopyNativeLibraries tests/GrindCore.Tests/GrindCore.Tests.csproj50-55 This target ensures that the correct architecture-specific binary is copied from the runtimes/ folder to the test output directory so the P/Invoke layer can locate it during execution.
Test Build Flow