Migrate BusinessMgr tests to NUnit
This commit is contained in:
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user