Testing Julia Code

Analogy categoryAnalogies

The Test Standard Library

Julia ships testing support in its standard library as the Test module, so no third-party package is required to write basic tests: using Test gives you the @test macro, which evaluates an expression and records a pass or fail without throwing, plus @test_throws for asserting that a specific exception type is raised, and @test_broken for marking a known-failing test so it doesn't silently disappear from the suite. Tests are typically grouped with @testset "description" begin ... end, which collects all @test results inside it into a named block, prints a clean pass/fail summary table at the end, and lets nested testsets organize a large suite hierarchically (a top-level testset per module, with nested testsets per function).

🏏

Cricket analogy: It's like a DRS review system built into every match by default rather than an optional add-on — Test being in Julia's standard library means every project gets @test and @testset without installing anything extra, the way DRS is simply part of how international cricket is officiated.

julia

using Test

function is_prime(n::Integer)
    n < 2 && return false
    for i in 2:isqrt(n)
        n % i == 0 && return false
    end
    return true
end

@testset "is_prime tests" begin
    @testset "known primes" begin
        @test is_prime(2)
        @test is_prime(17)
        @test is_prime(97)
    end

    @testset "known non-primes" begin
        @test !is_prime(1)
        @test !is_prime(4)
        @test !is_prime(100)
    end

    @testset "edge cases and errors" begin
        @test !is_prime(0)
        @test_throws MethodError is_prime(3.5)
    end
end

Package Structure and Continuous Testing

A proper Julia package generated with Pkg.generate or the PkgTemplates.jl package includes a test/runtests.jl file as the canonical entry point that Pkg.test("MyPackage") invokes; this file typically includes the package's Test dependency and organizes its own top-level @testset blocks, one per source file or feature area, so julia --project -e 'using Pkg; Pkg.test()' runs the entire suite in a fresh, isolated environment separate from your development environment. Test-specific dependencies (like Random for seeding reproducible random tests, or comparison helpers) belong in the package's [extras] and [targets] sections of Project.toml (or, in modern Julia, a separate test/Project.toml), keeping test-only dependencies out of the package's own runtime dependency graph that end users install.

🏏

Cricket analogy: It's like a franchise running its trial camp in a completely separate ground from the main squad's training facility — test/runtests.jl runs in its own isolated environment (Pkg.test) so trial results never contaminate the actual matchday squad.

Run ] test from the Pkg REPL mode (or Pkg.test() programmatically) rather than manually include-ing runtests.jl — the Pkg.test workflow instantiates a clean, isolated test environment so hidden dependency issues that would break for end users get caught early.

Property-Based and Approximate Testing

Numerical code rarely produces exactly reproducible floating-point results across platforms, so Julia's Test module provides @test a ≈ b (using the isapprox operator, typed as \approx<TAB>) with configurable atol (absolute tolerance) and rtol (relative tolerance) keyword arguments for comparing floating-point results within an acceptable margin rather than demanding bit-for-bit equality. For more thorough coverage than example-based tests, Supposition.jl or the older RandomizedPropertyTest.jl bring property-based testing to Julia, generating many randomized inputs to check that invariants (like sort(x) == sort(sort(x)) or is_prime(n) == is_prime(n) for repeated calls) hold broadly rather than just for a handful of hand-picked examples.

🏏

Cricket analogy: It's like a bowling machine calibrated to deliver within a tolerance band of 140-142 km/h rather than demanding the exact same 141.0 km/h every single ball — @test a ≈ b accepts a reasonable margin instead of impossible bit-exact equality.

Never compare floating-point results with == in tests. Two mathematically equal computations can differ in the last few bits due to floating-point rounding and the order operations were evaluated in, so @test a == b on floats is a common source of flaky, platform-dependent test failures — use @test a ≈ b atol=1e-8 instead.

Julia's Test standard library provides @test, @test_throws, and @test_broken with no external dependency required.
@testset groups related tests, prints a pass/fail summary, and can be nested for hierarchical organization.
The canonical package test entry point is test/runtests.jl, run via ] test or Pkg.test(), which uses an isolated environment.
Test-only dependencies belong in test/Project.toml (or [extras]/[targets] in Project.toml), not the package's main runtime dependencies.
Use @test a ≈ b with atol/rtol for floating-point comparisons instead of exact equality.
Property-based testing libraries like Supposition.jl generate randomized inputs to check invariants beyond hand-picked examples.
Never use == to compare floats in tests; floating-point rounding makes exact equality unreliable across platforms.