Ruby / Integration: data, resources, runtime evidence, and trust / Lesson 15

Make checks deterministic and dependencies explicit

Separate Ruby syntax, behavior checks, gem resolution, runtime version, and platform evidence in an isolated project.

About 5 min readContent reviewed 2026-10-28

On this page

Lesson goals

Design a meaningful boundary check that does not depend on real time or external services.
Explain why a Gemfile or lockfile is not an execution or compatibility certificate.

Different tools answer different questions

A syntax check asks whether the interpreter can parse a source file; it does not establish that the business rule is correct. A behavior test needs explicit expected outcomes and representative boundaries. A gem resolver chooses versions under constraints, while an integration test exercises a real dependency boundary. Keep these claims separate in reports. Ruby was not installed in the authoring environment, so this course performed none of those Ruby commands and installed no dependencies. A reasoned expected output remains useful teaching material only when it is labeled honestly rather than presented as a passing test log.

Pass changing context into the rule

A policy that reads the real clock, randomness, network, or global mutable state implicitly is harder to check reliably. Accept those values or collaborators explicitly so a small test can choose a stable case. The example uses integer minutes to explain a cutoff, not to solve time zones, daylight saving, or clock synchronization. Equality is deliberately rejected, which distinguishes < from <=. Use a domain-appropriate time type in a real application, and decide the rule with its owner before encoding the expected Boolean. A test that mirrors the implementation without an independent requirement can preserve the same mistake.

ruby A fixed cutoff harness with explicit mismatch failure

def before_cutoff?(now, cutoff)
  now < cutoff
end
[[9, true], [10, false], [11, false]].each do |now, expected|
  actual = before_cutoff?(now, 10)
  raise 'cutoff mismatch' unless actual == expected
end
puts '3 declared cases passed'

Expected output

3 declared cases passed

Expected output is 3 declared cases passed if the script is executed successfully. It was not run here, so this is not a recorded test pass.

Declare the runtime and gem environment independently

RubyGems packages libraries, and Bundler can describe and resolve an application’s declared dependencies. A Gemfile is Ruby code, not inert untrusted data. A lockfile records a resolved dependency selection, but platform, native extension, Ruby engine, and version requirements can still matter. Standard or default libraries can also have separately versioned gem packaging; do not assume every runtime installation provides the same set merely because the language version matches. Use the project’s existing dependency policy and authorized environment rather than installing global packages to make an example appear verified.

A declared range is a promise to verify

The illustrative Gemfile below chooses the Ruby 3.3 minor line and a public source without declaring external gems. It is a teaching constraint, not a recommendation that every project adopt that line or a claim that all patch versions were tested. No resolver or Bundler command was run. An application should test its actual minimum and deployed runtime, relevant engine, and target platform. When code adopts Data or another version-specific API, update and verify the runtime contract instead of silently relying on the author’s machine. Keep package metadata and execution evidence distinct.

ruby An illustrative Gemfile runtime declaration

source 'https://rubygems.org'
ruby '>= 3.3.0', '< 3.4.0'

This fragment belongs in a learner-owned local Gemfile and is not a standalone program. It was not evaluated, resolved, installed, or published.

Report exactly what ran and what remains untested

A useful result records interpreter version and engine, source revision, dependency state, command, fixtures, and observed output. Name fake collaborators and excluded boundaries so a local unit check is not mistaken for filesystem, network, database, or concurrency evidence. Testing one path does not certify every API or supported platform. Use a configured framework when it improves the project’s real checks, but declare its dependency rather than assuming availability. This course’s authoring validation checks JSON structure and bilingual technical alignment; it does not substitute for Ruby parsing, test execution, gem resolution, or production readiness review.

Common errors and fixes

A syntax check is reported as proof of the cutoff policy.

Why it happens: Parsing success was confused with behavior validation.
How to fix it: Execute meaningful cases against an independently stated requirement.
Prevent it next time: Label syntax, unit, integration, and platform results separately.

A locked dependency set fails on another native platform.

Why it happens: Resolution metadata was treated as universal runtime compatibility.
How to fix it: Verify engine, platform, native extension, and runtime requirements explicitly.
Prevent it next time: Include actual target environments in the compatibility plan.

An example is marked tested despite no interpreter.

Why it happens: Expected output was promoted into fabricated execution evidence.
How to fix it: Keep it unexecuted and state the missing tool accurately.
Prevent it next time: Require a command and captured result for every execution claim.

Check your understanding

1. Why should the cutoff check include exactly equal time?

Show worked solution

That case decides whether the rule uses < or <=. Earlier and later values can pass under both policies, hiding the important distinction. Establish the business decision first, then encode the fixed expected result and execute it in the real selected environment. A clear expected value is still not an observed pass until execution occurs.

2. Does a Gemfile with a Ruby requirement prove JSON is installed and usable?