Test iOS temperature conversions on a cloud Mac: values, deltas and display

When a weather or sensor app displays a rise of ten degrees Celsius as a rise of fifty degrees Fahrenheit, the problem is usually not formatting: a temperature delta has been converted as an absolute temperature. On a cloud Mac, you can establish the calculation contract in a standalone Swift test package before integrating it into an iOS project. No sensor connection or simulator launch is required.

Separate readings from deltas first

Converting an absolute temperature involves both a scale factor and an offset: zero degrees Celsius is thirty-two degrees Fahrenheit. A temperature delta involves only the scale factor: an increase of ten degrees Celsius is an increase of eighteen degrees Fahrenheit. Foundation’s Measurement<UnitTemperature> represents a temperature reading; it does not infer from a variable name that the value is a delta.

Make reading and delta explicit in the model, and document units in the API contract. Keep unformatted numeric values throughout the business layer, and choose decimal precision only when displaying them. Do not parse interface text such as “twenty-three point five degrees” back into a calculation input.

Temperature deltas can be negative; absolute temperatures below absolute zero must be rejected. The two fields cannot share the same range validation rules.

The validation below applies to physical temperatures. If the product handles mathematically extrapolated data, declare a separate range rather than silently relaxing input validation.

Create a UI-independent test package

First, check the toolchain and create a package in a separate directory so you do not change the existing project configuration. These commands require working Xcode command-line tools to be installed. The tests use the currently selected Swift toolchain.

xcrun swift --version
workdir="$(mktemp -d)"
cd "$workdir"
swift package init --type library --name TemperatureChecks

Keep the generated files, then save the code from the next section as Tests/TemperatureChecksTests/TemperatureContractTests.swift. It depends only on Foundation and XCTest; no external packages are needed.

The standalone package verifies conversion rules, not whether the iOS display meets acceptance criteria. After moving the tests into the project, have them call the production implementation. Otherwise, two copies of the functions can drift apart while the tests keep checking an outdated copy.

Lock down the rules with reference points and round trips

For absolute temperatures, first check that the input is finite, then convert it to kelvin to check the physical lower bound. For deltas, remove the offset by subtracting the converted origin from the converted endpoint. This approach is specific to the linear temperature conversions used here; do not apply it directly to arbitrary unit models.

import Foundation
import XCTest

private enum TemperatureError: Error {
    case invalidReading
}

private func kelvin(
    _ value: Double,
    from unit: UnitTemperature
) throws -> Double {
    guard value.isFinite else {
        throw TemperatureError.invalidReading
    }
    let result = Measurement(value: value, unit: unit)
        .converted(to: .kelvin).value
    guard result.isFinite, result >= 0 else {
        throw TemperatureError.invalidReading
    }
    return result
}

private func temperatureDelta(
    _ value: Double,
    from source: UnitTemperature,
    to target: UnitTemperature
) -> Double {
    let endpoint = Measurement(value: value, unit: source)
        .converted(to: target).value
    let origin = Measurement(value: 0, unit: source)
        .converted(to: target).value
    return endpoint - origin
}

final class TemperatureContractTests: XCTestCase {
    func testReferencePoints() throws {
        let freezing = Measurement(
            value: 0,
            unit: UnitTemperature.celsius
        ).converted(to: .fahrenheit).value
        XCTAssertEqual(freezing, 32, accuracy: 1e-9)
        XCTAssertEqual(
            try kelvin(0, from: .celsius),
            273.15,
            accuracy: 1e-9
        )
        XCTAssertEqual(
            try kelvin(-273.15, from: .celsius),
            0,
            accuracy: 1e-9
        )
    }

    func testTemperatureDeltas() {
        for value in [-10.0, 0.0, 10.0] {
            XCTAssertEqual(
                temperatureDelta(
                    value,
                    from: .celsius,
                    to: .fahrenheit
                ),
                value * 1.8,
                accuracy: 1e-9
            )
        }
    }

    func testRoundTrip() {
        for value in [-40.0, 0.0, 37.0, 100.0] {
            let original = Measurement(
                value: value,
                unit: UnitTemperature.celsius
            )
            let restored = original.converted(to: .fahrenheit)
                .converted(to: .celsius)
            XCTAssertEqual(
                restored.value,
                value,
                accuracy: 1e-9
            )
        }
    }

    func testInvalidReadings() {
        for value in [
            Double.nan,
            Double.infinity,
            -Double.infinity,
            -274.0
        ] {
            XCTAssertThrowsError(
                try kelvin(value, from: .celsius)
            )
        }
    }
}

Run swift test from the package root. The tolerance accommodates floating-point arithmetic error; it is not the error margin allowed by the application. Define sensor accuracy separately rather than hiding errors by increasing assertion tolerances.

Round-trip tests are no substitute for reference points, either: if errors in the two conversion directions cancel each other out, the round trip can still pass. Retain at least four categories of samples: zero, negative values, known reference values, and invalid inputs. The delta input boundary must also reject nonfinite values itself; the helper above demonstrates conversion only and does not validate inputs.

Validate localization separately from numeric precision

Save the following code as format-temperature.swift in the package directory, then run it with swift format-temperature.swift. The unit is fixed to Celsius so regional preferences cannot change it automatically, leaving only the display rules under test.

import Foundation

for identifier in ["zh_CN", "en_US", "fr_FR"] {
    let locale = Locale(identifier: identifier)
    let formatter = MeasurementFormatter()
    formatter.locale = locale
    formatter.unitOptions = .providedUnit
    formatter.unitStyle = .short
    formatter.numberFormatter.locale = locale
    formatter.numberFormatter.minimumFractionDigits = 1
    formatter.numberFormatter.maximumFractionDigits = 1

    let reading = Measurement(
        value: 23.45,
        unit: UnitTemperature.celsius
    )
    print(identifier, formatter.string(from: reading))
}

Check the decimal separator, unit symbol, and spacing, but do not assume the entire string will be identical across operating system versions. If you need snapshot assertions, record the operating system version and locale identifier as well.

Do not leave delta display to an absolute-temperature formatter’s implicit behavior. Calculate the delta in the target unit first, then use a number formatter and localized resources to label it explicitly as a “temperature difference.” Negative zero also needs a product rule: if rounding produces zero, handle whether to remove the minus sign consistently in the display layer.

Preserve three boundaries when integrating into the project

First, raw data must carry its unit. Do not interpret an unknown unit as Celsius by default: incorrect data can still fall within a plausible range. Unknown enum values in the protocol must return an explicit error.

Second, compare thresholds using unrounded values in a common unit. Two readings that display as the same number do not necessarily produce the same alert outcome. Add a case with “different values, identical display” to prevent UI refactoring from changing business decisions.

Third, passing Foundation tests on the cloud Mac does not remove the need to check formatting and layout in the target iOS runtime environment. Validate widgets, chart axis labels, and spoken output separately; checking only the main screen is not enough.

Finally, retain the test results, toolchain version, and formatted output. When a regression occurs, first determine whether it affects conversion, the input contract, or display, then change the appropriate layer. Do not rely on a single UI string assertion to establish correctness across all of them.

Frequently asked questions