d2d4db492b
maxParallelThreads was unset everywhere and only 3 of ~20 test projects carried an xunit.runner.json at all, so xunit ran Environment.ProcessorCount collections at once (14 on the dev box) in every suite. That is the general load multiplier behind the row-82/91/95 flake family. Policy: per-suite caps, NOT a global one. Pure unit suites stay uncapped for speed; a suite gets a config only when a test CLASS costs a real external or OS-level resource, so ProcessorCount of them at once is a resource question rather than a CPU question. Four suites qualify, all capped at maxParallelThreads: 4. - ConfigurationDatabase.Tests, AuditLog.Tests, SiteCallAudit.Tests — verified as the three that actually take MsSqlMigrationFixture (the latter two by project reference). Every MSSQL-backed test class means a CREATE DATABASE plus the ~100-migration chain against the one shared dev SQL Server. 4 is chosen to MATCH the default slot count of row 82's cross-process sp_getapplock migrate semaphore, so the in-process and cross-process limits agree rather than fighting. - Host.Tests — classes boot real ASP.NET Core hosts and real ActorSystems; Akka.Remote binds real sockets, Kestrel binds real ports, gRPC dials them. Threads are capped, collections are NOT serialized. IntegrationTests (parallelizeAssembly/parallelizeTestCollections false) and CentralUI.PlaywrightTests (maxParallelThreads 1) already carry stricter pre-existing settings and are left alone — the Playwright suite drives a browser against a live rig, where shared UI state, not CPU, is the constraint. Each capped csproj gains <Content Include="xunit.runner.json" CopyToOutputDirectory="PreserveNewest" />; the SDK does not copy it automatically and without it the file is silently ignored. Verified by moving the copied file out of bin/ to take an uncapped baseline: ConfigurationDatabase.Tests ran at 216 % CPU uncapped vs 145 % capped, so the cap demonstrably takes effect. Cost is close to nil — these suites are latency-bound on an external resource, not CPU-bound (14-25 % utilisation for the two slowest). Standalone, uncapped -> capped: AuditLog 383 tests 1m52s -> 1m51s; Host 520 tests 4m05s -> 4m08s; ConfigurationDatabase 396 tests 10s -> 12s; SiteCallAudit 66 tests 8s -> 8s. All green. docs/test_infra/test_infra.md gains a Test Parallelism Policy section: the two axes (in-process collection threads = this cap; cross-process solution-level dotnet test = unbounded in general, bounded on the DB-migration path by the sp_getapplock semaphore), the per-suite table with reasons, the rules (cap threads rather than serialize; a cap is not a substitute for test isolation; the Content copy is required), and the default for new projects (no config until the project acquires a per-class external resource). test_infra_db.md cross-links it from the semaphore bullet.
68 lines
3.2 KiB
XML
68 lines
3.2 KiB
XML
<Project Sdk="Microsoft.NET.Sdk">
|
|
|
|
<PropertyGroup>
|
|
<TargetFramework>net10.0</TargetFramework>
|
|
<ImplicitUsings>enable</ImplicitUsings>
|
|
<Nullable>enable</Nullable>
|
|
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
|
|
<IsPackable>false</IsPackable>
|
|
</PropertyGroup>
|
|
|
|
<ItemGroup>
|
|
<PackageReference Include="coverlet.collector" />
|
|
<!--
|
|
Bundle C migration integration tests need Microsoft.Data.SqlClient. EF
|
|
SqlServer 10.0.7 pulls in SqlClient >= 6.1.1, but the central package
|
|
version is pinned at 6.0.2 (the version the production
|
|
ExternalSystemGateway uses). Override the version locally for the test
|
|
project only; production assemblies are unaffected.
|
|
-->
|
|
<PackageReference Include="Microsoft.Data.SqlClient" VersionOverride="6.1.1" />
|
|
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" />
|
|
<!-- Security pin: GHSA-2m69-gcr7-jv3q. Microsoft.Data.Sqlite pulls the
|
|
vulnerable native 2.1.11; 2.1.12 patches it. Bumping Sqlite does not help. -->
|
|
<PackageReference Include="SQLitePCLRaw.lib.e_sqlite3" />
|
|
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" />
|
|
<PackageReference Include="Microsoft.AspNetCore.DataProtection" />
|
|
<PackageReference Include="Microsoft.AspNetCore.DataProtection.EntityFrameworkCore" />
|
|
<PackageReference Include="Microsoft.Extensions.DependencyInjection" />
|
|
<PackageReference Include="Microsoft.NET.Test.Sdk" />
|
|
<PackageReference Include="xunit" />
|
|
<PackageReference Include="xunit.runner.visualstudio" />
|
|
<!--
|
|
SkippableFact lets the Bundle C MSSQL integration tests report as Skipped
|
|
(not Passed) when the dev MSSQL container is not running. xunit 2.9.x does
|
|
not ship Assert.Skip / SkipUnless — those are v3-only — so we use the
|
|
canonical community wrapper instead.
|
|
-->
|
|
<PackageReference Include="Xunit.SkippableFact" />
|
|
</ItemGroup>
|
|
|
|
<ItemGroup>
|
|
<Using Include="Xunit" />
|
|
</ItemGroup>
|
|
|
|
<ItemGroup>
|
|
<!--
|
|
Deferred-work register row 96 — per-suite in-process parallelism cap.
|
|
This is the suite that owns MsSqlMigrationFixture: every MSSQL-backed test
|
|
CLASS gets its own database, i.e. a CREATE DATABASE plus the full
|
|
~100-migration chain against the ONE shared dev SQL Server. Uncapped,
|
|
xunit runs Environment.ProcessorCount collections at once, so a 14-core
|
|
dev box asked the server for 14 concurrent fresh-database migrations from
|
|
this process alone. The cap is threads only — collections stay parallel —
|
|
and 4 matches the default slot count of the cross-process sp_getapplock
|
|
migrate semaphore (row 82), so the in-process and cross-process limits
|
|
agree. Policy: docs/test_infra/test_infra.md.
|
|
The json must be copied to the output directory to take effect.
|
|
-->
|
|
<Content Include="xunit.runner.json" CopyToOutputDirectory="PreserveNewest" />
|
|
</ItemGroup>
|
|
|
|
<ItemGroup>
|
|
<ProjectReference Include="../../src/ZB.MOM.WW.ScadaBridge.ConfigurationDatabase/ZB.MOM.WW.ScadaBridge.ConfigurationDatabase.csproj" />
|
|
<ProjectReference Include="../../src/ZB.MOM.WW.ScadaBridge.Commons/ZB.MOM.WW.ScadaBridge.Commons.csproj" />
|
|
</ItemGroup>
|
|
|
|
</Project>
|