Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/V3RNE42/helios/llms.txt

Use this file to discover all available pages before exploring further.

Helios’s test suite focuses on computeRouteSections — the core solar routing algorithm — which is designed to be pure and dependency-injectable, making it straightforward to test without a browser or API keys.

​
Running the tests

Run the full test suite from the project root: 
npm test
This executes vitest run (a single non-watch pass) and processes routeSolar.test.js. No browser, no live network requests, no build step required.
No environment variables or API keys are required to run the tests. The getOffset dependency is injected as a mock — async () => 2 — so the timezone serverless function is never called.
Node.js 24.x is required, as declared in the engines field of package.json: 
{
  "engines": {
    "node": "24.x"
  }
}

​
What is tested

routeSolar.test.js contains two describe blocks.

​
computeRouteSections

Four focused unit tests exercise the algorithm across its main operating modes:
  1. Daytime north-to-south trip — A Madrid → Málaga journey on 15 June 2026 (09:00–15:00 UTC, midsummer). Asserts that night === false, that the returned sections array contains at least two dated entries, that the first entry’s timestamp equals the departure time, and that the last entry’s timestamp equals the arrival time.
  2. Fully nocturnal trip — An Oslo → Oslo trip on 15 January 2026 (20:00 UTC departure, 04:00 UTC arrival the following day). January nights in Oslo are long enough that the entire journey falls outside daylight. Asserts night === true and that at least two sections are returned without throwing.
  3. Multi-day trip — A Madrid → Málaga journey spanning three days (15–18 June 2026). Asserts that the sections array has more than two entries and that every consecutive pair of timestamps is strictly increasing, confirming the algorithm marches forward through time correctly.
  4. Convergence failure — Passes a degenerate getDayInfo stub that always returns new Date(0) for both sunrise and sunset, ensuring the inner convergence loop can never be satisfied. Asserts that computeRouteSections throws rather than hanging indefinitely (the function enforces a hard limit of 100 000 inner iterations before raising an error).

​
consistencia entre las dos implementaciones solares

One cross-implementation sanity check:
  • Solar noon agreement — Calls both getTimes(d, lat, lon).solarNoon (from suncalc.js) and getDayInfo(d, lat, lon).transit (from SunCalc_function.js) with the same date and Madrid coordinates, then asserts that the two values agree to within 5 minutes. This guards against drift between the two solar libraries that ship with Helios.

​
Test fixtures

Three coordinate constants are defined at the top of routeSolar.test.js and reused across tests:
ConstantCoordinatesPurpose
MADRID{ lat: 40.4168, lon: -3.7038 }Origin for north → south daytime trips
MALAGA{ lat: 36.7213, lon: -4.4214 }Destination for Madrid-based trips
OSLO{ lat: 59.9139, lon: 10.7522 }High-latitude location for polar/nocturnal edge cases
A shared fakeOffset stub — async () => 2 — is declared once and passed as getOffset for every test. Because all tests use local: false, getOffset is never actually invoked by the algorithm; the stub exists only to satisfy the function signature.

​
Writing new tests

To add a test case:
  1. Import computeRouteSections from ./routeSolar.js.
  2. Import sunCalcFactory from ./SunCalc_function.js to obtain a real getDayInfo.
  3. Pass async () => 0 as a getOffset stub for any test that does not exercise timezone-offset logic. Note that the existing suite uses async () => 2 — the value returned does not affect the algorithm when local: false, so either constant works; using 0 in new tests avoids implying a specific UTC offset.
  4. Set local: true and supply a real (or more elaborate) async getOffset stub only when you specifically need to test how the UI renders UTC-offset data.
Here is a minimal skeleton that follows the same conventions as the existing suite: 
import { describe, it, expect } from 'vitest';
import { computeRouteSections } from './routeSolar.js';
import sunCalcFactory from './SunCalc_function.js';

const { getDayInfo } = sunCalcFactory();
const fakeOffset = async () => 0;

describe('my new test', () => {
    it('does something specific', async () => {
        const { sections, night } = await computeRouteSections({
            start: { lat: 40.4168, lon: -3.7038 },
            end:   { lat: 36.7213, lon: -4.4214 },
            diasalida:  new Date(Date.UTC(2026, 5, 15, 9, 0)),
            diallegada: new Date(Date.UTC(2026, 5, 15, 15, 0)),
            local: false,
            getDayInfo,
            getOffset: fakeOffset
        });
        expect(night).toBe(false);
    });
});

​
What is not tested

The test suite covers only the pure algorithmic core. The following are not covered by automated tests:
  • Browser UI (index_def.js) — the multi-step form, validation, and results rendering have no automated tests.
  • Serverless functions (api/geocode.js, api/timezone.js) — the Nominatim/OpenCage geocoding pipeline and the ipgeolocation.io/TimeZoneDB timezone pipeline are untested.
  • Live API integration — no test makes a real network call to any geocoding or timezone service.
Because computeRouteSections receives getDayInfo and getOffset as injected parameters, you can swap in any solar calculator implementation you like — not just the bundled SunCalc_function.js. This makes it straightforward to test the routing logic against alternative ephemeris libraries or hand-crafted stubs without touching production code.

Build docs developers (and LLMs) love

Get started for freeTalk to us