Get useful test feedback at a Singapore developer code review session

The problem

A junior Singapore developer asks peers to review a change, but the discussion stays on style because the intended behaviour and test boundary are unclear.

Write the requirement before asking for a code verdict

Start with the observable result the change is intended to produce and the behaviour it must leave intact. Add the reason for that requirement, the permitted input and one explicit exclusion. If the intended behaviour is disputed, ask about it before treating a test as proof that your implementation is right. A small diff can affect a shared path, while a larger example can still answer one bounded question. Prepare a behaviour card: task; required result; unaffected behaviour; changed part; evidence available; and unresolved condition. Keep the proposed implementation beside that card rather than using the code itself as the only statement of the requirement. This guide addresses review of a change’s test boundary; the debugging guide addresses making an unexplained symptom repeatable.

Choose cases that expose different mistakes

For each proposed input, write the expected observation and the specific mistaken behaviour it could reveal. Use an ordinary case, a contrasting boundary case and a clearly identified unsupported condition when those suit the task. Several copies of the same happy path may establish less than one contrast that separates two plausible implementations. An unsupported input needs its actual expected handling or an explicit exclusion; do not invent a required result to complete the table. The record should answer “What would this observation tell us?” rather than “How many tests can I show?” Label wholly invented fixtures as practice inputs. They can explain a testing question without establishing how an external service or a real user behaves.

Locate what your own check can control

Show where the changed code receives its input, produces its result and depends on a service or framework. Ask which observation belongs to your local behaviour and which needs the applicable external contract. The retained data.gov.sg search documentation describes paginated row scanning and query parameters; it offers a real public-data context for discussing a client’s behaviour without defining every API. A local practice check can examine what the client does with a supplied response, while leaving the actual service’s response conditions unverified. Keep that distinction when using fixtures. Check the actual pagination, text-filter, dataset-identity or failed-versus-empty condition that your local behaviour depends on. No fixture in this article promises a real endpoint response or supplies an installation instruction.

• Data.gov.sg search and filter within dataset ↗ · Source checked 20 October 2026

Complete an invented target-change table

Every record, version and outcome in this example is fictional. Three practice notes have stable identifiers A, B and C. A and B both display Draft; C displays Final. The stated task is to change A’s label to Ready while leaving B’s Draft and C’s Final unchanged, with the same three identifiers. A one-note input containing only A cannot distinguish a version that targets A from a version that changes every Draft label. On the three-note input, invented Version R produces A Ready, B Ready and C Final. R changes B outside the stated task. Invented Version Q produces A Ready, B Draft and C Final. That matches this input’s specified label observations. The completed table exposes a wrong change that the one-note case missed; it supplies no tested code or result about a real dataset.

Ask whether the proposed assertion would catch the wrong version

Keep the selected input, version and expected observations together. In the fictional case, checking only that A is Ready would pass for both R and Q, leaving the demonstrated B error undetected. Checking the specified A, B and C labels on that input distinguishes those fictional outputs. Retaining the identifiers and their count is another stated requirement, not a claim that checking labels also checks everything else. A review question can be: “Which expected observation would make this deliberately wrong version fail, and what does the proposed check still omit?” Use an authorised disposable exercise when trying that comparison. Record a check as planned until it is actually run, and retain the observation for the exact version. Do not alter a production system or present a handwritten table as an executed software test.

Keep a passing case at the scope it establishes

A useful result note names the changed version, fixture, expected observation, actual observation and limit. In the invented Q case, the three recorded label results match the stated table. That does not establish behaviour for an absent target, a duplicate identifier, concurrent changes, persistence or an external data source. Identify any such condition that matters to the actual task and obtain its expected handling before widening the claim. A peer may suggest another useful case without deciding that your application requires it. Likewise, a style improvement can make code easier to inspect while supplying no missing behavioural evidence. Keep requirements, reviewer advice and observations in separate entries so a passing local case does not become a claim of complete coverage or deployment readiness.

Bring the narrow review question through the offered route

Confirm whether participants may show their own small change, what preparation is expected and which material the session accepts. Supply the behaviour card, the relevant permitted excerpt and the contrasting cases; remove unavailable information without silently changing the example’s meaning. Ask about a single unresolved assertion or boundary rather than requesting approval of the whole architecture. An unsent question could say: “This change should affect one identified practice note. These two versions both pass my one-note case, but one changes another note in the contrast. Does the proposed assertion expose that mistake, and which relevant behaviour is still untested?” SGInnovate’s directory remains discovery context, not an allocated reviewer or project representative. For a later project submission, check the maintainer’s actual repair request or declined scope; peer testing discussion does not settle that decision.

• SGInnovate events directory ↗ · Source checked 20 October 2026

Record the next evidence step without expanding the patch

After review, keep the requirement clarified, the assertion or boundary proposed, any observation actually obtained and the question still open. If a peer recommends a change, check that it addresses the agreed behaviour instead of adding a neighbouring feature. Retain earlier results when the example or requirement changes so another reviewer can see which claim each supports. An applicable project process may still require a separate submission and acceptance; a shared-session comment is not integration or release. Use Boardzip’s free testing and code-review search to find an appropriate format, then verify the organiser’s actual instructions. A useful outcome may be one stronger contrast or an unresolved external-contract question. Describe that outcome accurately without counting attendance, test length or a confident review comment as proof of the whole application.