RobotnixAcademy

Unit 17 · lesson

Select Java and WPILib Evidence That Actually Tests a Requirement

A capstone is not stronger because it contains every code block you wrote.

Choose evidence that answers a specific readiness claim.

For the Java/WPILib side, three kinds of evidence are especially useful:

  • a unit test around a boundary;
  • an invalid-input/state-preservation case;
  • a runtime/log record when runtime context matters.

Choose one boundary test

A strong example from Unit 5 is the strict caution-distance rule:

0.49 m -> stop=true
0.50 m -> stop=false
0.51 m -> stop=false

The important evidence is not only that the tests passed.

The test set exposes the difference between:

rangeMeters < cautionDistanceMeters

and:

rangeMeters <= cautionDistanceMeters

A boundary defect could pass many comfortable inputs and still fail the exact requirement.

Include the requirement beside the test

Do not paste a JUnit screenshot with no context.

Write:

Requirement:
Stop only when range is strictly less than 0.50 m.

Then include the test cases and result.

A reviewer can now see why those three values were selected.

Choose one invalid-state test

Use a component such as the validated range sensor.

A useful readiness claim is:

An invalid range update is rejected without replacing the last accepted range.

The evidence should include:

  • valid starting state;
  • invalid request;
  • expected exception;
  • state read after rejection.

For example:

accepted state before invalid update: 0.42 m
invalid request: 3.70 m
result: IllegalArgumentException
state after rejection: 0.42 m

This proves more than an exception alone. It verifies the object did not corrupt its previous valid state.

A runtime log answers a different question

JUnit can prove controlled behavior for selected inputs.

A runtime log can show what values and events were observed during a particular execution.

From Unit 5, useful runtime evidence might include:

raw range input
accepted range state
modeled healthy flag
rejection message

Choose runtime logging only if it supports a claim in your matrix.

Do not include logs simply because logs look technical.

Label supplied and local evidence

If you executed WPILib/JUnit locally, write:

local execution evidence

and preserve the command/tool context.

If you used the course's deterministic/supplied record, write:

supplied course evidence

The two paths can teach the same reasoning. They are not the same provenance.

Do not claim hardware from software tests

A passing test can support:

the Java method returned the expected result for these inputs

It cannot support:

the physical robot stopped at the correct distance

A software rule may be correct while:

  • the sensor value is stale;
  • the unit conversion is wrong;
  • the motor controller is disconnected;
  • another layer ignores the result.

Keep hardware deployment claims separate.

Include one deliberately failing test if you used it to repair a defect

A good engineering portfolio can include a failure.

Suppose the implementation accidentally uses:

<=

The exact-boundary test fails.

You repair the code to:

<

and rerun the suite.

The failure/repair record shows that the test suite can actually detect the defect it claims to protect.

That is stronger evidence than a suite that has only ever been observed passing.

Write the Java evidence section as a small argument

A strong section contains:

Claim

What Java behavior is being defended?

Requirement

What should happen?

Test/runtime evidence

What exact cases or records support the claim?

Result

Pass, conditional pass, blocked, or not demonstrated.

Limitation

What stronger runtime/hardware claim remains outside the evidence?

The format makes evidence easier to review than a folder of screenshots.

Worked example

Claim

ValidatedRangeSensor preserves the last valid state after an invalid update.

Requirement

Range values must remain within 0.10..2.00 m; invalid values are rejected before assignment.

Evidence

updateRange(0.42) accepted
updateRange(3.70) throws IllegalArgumentException
getRangeMeters() returns 0.42 afterward

Status

Pass for the tested Java component behavior

Limitation

Does not prove a physical sensor or ROS topic produced 0.42 or 3.70 m.

That row is capstone-ready.

Your turn

Choose exactly three Java/WPILib evidence items:

  1. one boundary test;
  2. one invalid-input or state-preservation test;
  3. one runtime/logging or simulation record if it supports a matrix claim.

For each, write the five-part evidence argument above.

Then remove any extra Java artifact that does not support a distinct readiness claim.

In the next lesson, you will do the same thing on the ROS side: select graph, topic/interface, configuration, and bringup evidence without turning the dossier into a command transcript dump.