Development and Test Workflow

Choose a component from the failure boundary

For a malformed CLI input accepted as valid, begin with sonic-utilities parsing and validation. For a missing route dependency retry, inspect SWSS RouteOrch and its tests. For serialization or vendor API invocation, inspect sonic-sairedis/syncd. An ASIC SDK defect may require vendor evidence and is not repaired by an arbitrary configuration edit.

The existing Windows checkout is an additional read-only reference: buildimage 128f6802b6e1, utilities cc4fbb3e8313, SWSS b8a9b65494c2, SAI Redis dd925f4cf6fa. It differs from the selected community202505 source baseline. Do not equate a local commit with the binary running on a switch.

Define the smallest meaningful regression

Example proposal: a route arrives before its next-hop dependency, then the neighbor becomes available. The regression should verify no premature usable route claim, eventual route readiness after the dependency appears, and deletion/cleanup of the created objects. Compare a negative case as well as the happy path.

Use the repository’s existing fixtures, schema, polling helpers, and test conventions. The inspected SWSS route tests show DVS/ASIC_DB checks; they are not standalone scripts suitable for an arbitrary Windows shell. A unit mock verifies a branch; a DVS test verifies a broader software boundary; physical validation remains separate.

Proposed test record:
Arrange: missing next hop
Act: request route, then provide dependency
Assert: pending first; ready only after prerequisite
Cleanup: route and dependent lab objects removed
Status: design example, not executed

Illustrative shortened output, not a device observation.

Keep a reviewable change and evidence trail

# Examples for an approved isolated development checkout only
git status --short
git diff --check
git diff --stat

Those Git commands inspect the development work; they do not build SONiC or validate packet behavior. Follow the chosen repository’s contribution and test instructions. Record base commit, changed component, failing-before/passing-after test evidence when actually run, and any compatibility impacts.

Do not clone large repositories, install dependencies, or start a full image build just to make a documentation change. A build plan should name target platform/release, resources, dependencies, artifacts, and owners; execute it only in a separately authorized environment. No build commands are presented as already performed.

Failure diagnosis and completion criteria

If a test passes only after a long sleep, investigate the readiness predicate and fixture cleanup before increasing delays. If a source change passes mocks but fails packet tests, preserve the boundary mismatch rather than claiming the mocks proved forwarding.

Before review, explain the concrete trigger, resulting behavior, smallest patch, test scope, and residual risks. Restore disposable fixture state and keep the user’s reference checkout unchanged. A reviewed patch, virtual result, and hardware qualification are different milestones. This lesson completes the bounded curriculum; it does not claim production certification or authorize a deployment.

Check your understanding

Six questions, four options each. Check each answer for an explanation, review your score, and retry.