# C# Testing Guidelines

> Test strategy for Kingdee Enterprise C# plugins, services, and integration adapters.

---

## Scope

Use this guide for C# unit tests, service tests, and plugin behavior tests. Some Kingdee plugin classes are difficult to instantiate outside the platform runtime; in that case, extract testable business logic into services/helpers and keep plugin tests focused on adapter behavior.

---

## Test Layers

| Layer | Goal | Preferred style |
| --- | --- | --- |
| Pure helper/service | Business rules, mapping, validation | Unit tests with normal .NET test framework |
| Integration adapter | Request mapping, response handling, retries | Unit tests with mocked HTTP/client dependency |
| Plugin adapter | Lifecycle dispatch and field extraction | Thin tests with mocked context/model when feasible |
| Platform runtime path | Save/submit/list behavior in real system | Manual or integration checklist when local runtime is required |

---

## Coverage Expectations

- Cover happy path, validation failure, business rejection, dependency failure, and unexpected exception.
- Cover entry-row boundary cases: zero rows, one row, multiple rows, missing required fields.
- Cover retry/idempotency behavior for operation plugins and external integrations.
- Verify no downstream service call happens after early validation failure.

---

## Test Data Rules

- Use builders/factories for DynamicObject-like test data.
- Keep field keys in constants shared with production mapping code where possible.
- Avoid tests that only assert no exception; assert returned result, message, changed field, or service call.
- Do not depend on localized captions as test identifiers.

---

## Commands

Use the command defined by the target project. Typical examples:

```bash
dotnet test
msbuild /t:Build
```

If the project is Visual Studio-only or requires Kingdee runtime assemblies unavailable locally, report:

- Which command could not run
- Which dependency is missing
- Which source-level checks were performed instead

---

## Review Checklist

- [ ] Tests are close to the behavior being changed.
- [ ] Platform runtime gaps are isolated behind interfaces or helpers.
- [ ] Mocks verify early-return and failure paths.
- [ ] Boundary values are explicit.
- [ ] Build/test limitation is documented if tests cannot run locally.

---

## Minimal Test Example

```csharp
public sealed class PayServiceTests
{
    [Fact]
    public void Submit_ReturnsFailure_WhenRequestIsNull()
    {
        var service = new PayService();

        var result = service.Submit(null);

        Assert.False(result.Success);
        Assert.Equal("请求不能为空。", result.Message);
    }
}
```