Testing Unit Conversion at the Edges of a Sensor Range
From the earlier reference collection. Read the current software blog.
A small conversion test suite should cover exact values, negative inputs, rounding boundaries, missing data, and explicit source and display units.
Keep units attached to values
A conversion function should accept a numeric value with a known source unit and return a value in an explicitly selected display unit. Do not let a bare number travel through the program with an implicit assumption. A record such as value=12.0, unit=°C is safer than a field named temperature whose unit is only understood by one screen.
For Celsius to Fahrenheit, the familiar relation is F = C × 9/5 + 32. Unit conversion changes representation; it does not change the underlying observation. Preserve the source value and unit if users may need to compare the displayed result with source data.
Test ordinary and boundary values
Start with values whose results are easy to check: 0°C becomes 32°F, and 100°C becomes 212°F. Add a negative value, such as −10°C becoming 14°F, to catch implementations that mistakenly treat the input as a nonnegative sensor reading. The software should convert mathematical inputs consistently even if a particular sensor would never report them.
Test around rounding boundaries. If the interface displays one decimal place, choose values that round down, round up, and sit near the halfway point. Assert the numeric conversion separately from formatting, since binary floating-point representation can make an exact halfway case surprising. Define whether the display uses a specific rounding rule.
Treat missing data as missing
Test null, an absent field, an empty string, and malformed text according to the importer’s contract. These are not temperatures and should not silently become zero. Zero is a valid numerical reading in many scales, so using it as a stand-in for missing input can create a convincing false result.
Also reject unsupported unit labels explicitly. If a reading arrives with a unit the program does not understand, preserve the raw record for diagnosis and report a validation error rather than displaying a converted number with a guessed scale.
Separate conversion from measurement
A focused test can assert three things: the original observation remains unchanged, the converted number matches the formula within a chosen tolerance, and the display includes the target unit. For instance, a 20°C observation may be rendered as 68°F while its stored source value stays 20°C. This catches code that overwrites raw measurements during presentation.
Water temperature readings make this exercise concrete because charts may show either source units or converted values. A public temperature page is a context for inspecting labels, not proof of its sensor range or conversion behavior. Test the boundaries your own import and display contracts actually promise.