Migrate BusinessMgr tests to NUnit

This commit is contained in:
Andy Howard
2026-09-15 10:29:35 +01:00
parent 3f2f8c16ef
commit de07f2120f
16 changed files with 333 additions and 411 deletions
+3 -3
View File
@@ -18,7 +18,7 @@ dotnet run --project SaBusinessMgrCoreWebControl
dotnet run --project SaBusinessMgrCoreWebPortal
```
For the standard repository validation, run `./eng/validate.ps1`. It selects Visual Studio MSBuild for the SSDT-dependent Portal test project, runs both test assemblies, and performs repository checks; see `eng/README.md`.
For the standard repository validation, run `./eng/validate.ps1`. It restores and builds the solution with the .NET CLI, runs both NUnit test projects, and performs repository checks; see `eng/README.md`.
When validation requirements, solution structure, target frameworks, test projects, package-audit scope, or required tooling change, update `eng/validate.ps1` and `eng/README.md` as part of the same change. Run the updated script before handoff. Do not bypass a failing validation stage without documenting the reason.
@@ -30,7 +30,7 @@ For changes to Common public APIs, target frameworks, packages, or shared behavi
Match existing C# conventions: tabs, braces on new lines, top-of-file `using` directives, PascalCase public members, and established `Sbm`/`Sacs` prefixes. Tests use descriptive names such as `Test_Application_ControlDatabase`. No repository-wide formatter is configured, so follow nearby code. Target the framework versions declared in project files. Do not upgrade frameworks or NuGet packages unless explicitly requested.
Across all code files that support `//` line comments, use meaningful section comments instead of solid decorative comment lines. Format a section delimiter as `// --- Caption ---`, where the caption describes the code that follows, such as `Data Members`, `Construction`, `Properties`, `Test Support`, or another context-specific description. Reserve `Utilities` for internal methods that provide relatively simple supporting functionality; use a more specific caption for complex or domain-significant behavior. A delimiter may be followed by explanatory comments when useful. Surround the complete comment block with a blank line so it is visually separate from the preceding and following code; omit only the outside blank line that would otherwise appear directly after an opening brace or directly before a closing brace. Finish the file's main outer class or type block with `// --- The End ---` immediately before its closing brace. Leave nested or internal classes/types comment-free unless the type is complex enough to warrant sections and is at least 32 lines long; `// --- The End ---` is not required for such nested types. Do not add other delimiters where they do not clarify a distinct section. Apply this convention to new files. When an existing file receives significant modification, bring its section comments into line throughout that file as part of the same edit; small, isolated changes do not require unrelated wholesale reformatting.
Across all code files that support `//` line comments, use meaningful section comments instead of solid decorative comment lines. Format a section delimiter as `// --- Caption ---`, where the caption describes the code that follows, such as `Data Members`, `Construction`, `Properties`, `Test Support`, or another context-specific description. `Definitions` is appropriate where the following code declares classes, structs, interfaces, enums, or similar types. Reserve `Utilities` for internal methods that provide relatively simple supporting functionality; use a more specific caption for complex or domain-significant behavior. A delimiter may be followed by explanatory comments when useful. Surround the complete comment block with a blank line so it is visually separate from the preceding and following code; omit only the outside blank line that would otherwise appear directly after an opening brace or directly before a closing brace. Finish the file's main outer class or type block with `// --- The End ---` immediately before its closing brace. Leave nested or internal classes/types comment-free unless the type is complex enough to warrant sections and is at least 32 lines long; `// --- The End ---` is not required for such nested types. Do not add other delimiters where they do not clarify a distinct section. Apply this convention to new files. When an existing file receives significant modification, bring its section comments into line throughout that file as part of the same edit; small, isolated changes do not require unrelated wholesale reformatting.
Processes derived from `SaProcess_Base` must actively poll `IsInterrupted` during long-running loops and before expensive or blocking stages, then exit promptly when cancellation is requested.
@@ -49,7 +49,7 @@ table td {
## Testing Guidelines
Tests use MSTest with Moq and coverlet. Add `[TestClass]` and `[TestMethod]` attributes and place tests in the project matching the affected application. Run the relevant test project after a change, and run the full solution tests when the change crosses project boundaries. Several tests access configured databases and are integration-oriented; verify machine configuration and test data before assuming failures are isolated unit-test regressions.
Tests use NUnit with Moq and coverlet. Add `[TestFixture]` and `[Test]` attributes, use the NUnit constraint model with `Assert.That` wherever possible, and place tests in the project matching the affected application. Run the relevant test project after a change, and run the full solution tests when the change crosses project boundaries. Several tests access configured databases and are integration-oriented; verify machine configuration and test data before assuming failures are isolated unit-test regressions.
## Change Discipline