Files
alpenwerk-hr/tests/unit/employee-sort.test.ts
Maximilian Stubhan 5c310c3a58
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 6m12s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m29s
Let the employee list be sorted A-Z or Z-A
Sorting lives in the URL, not the browser. The list is built on the
server and fetched a page at a time, so a client-side sort would only
reorder the fifteen rows on screen — with 867 people that promises an
alphabetical list and delivers something else on page 2.

The sort key is the surname, because that is how the column reads:
"Aigner, Manuel", and whoever looks for someone looks under A. Postgres
runs with the Austrian collation, so Ö sorts with O rather than at the
end of the alphabet.

Only the surname reverses. The id stays ascending: it decides nothing
except ties, and it exists to keep the order total across page
boundaries. Reversing it too would still be deterministic but would flip
the fourteen Winklers relative to each other for no reason anyone asked
for.

The select sits in the filter bar rather than in a clickable column
header — a header would suggest it sorts what is on screen.

Verified: compiled SQL is `order by last_name desc, id` for Z-A; the
parse and direction rules are covered by tests that were mutation-checked
(breaking each rule turns them red). Not verified in the browser — the
login goes through the company account, and the Supabase instance no
longer resolves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 10:02:40 +02:00

46 lines
1.7 KiB
TypeScript
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

import { describe, expect, it } from "vitest";
import { SORTIERUNGEN, STANDARD_SORTIERUNG, parseSortierung, richtung } from "@/lib/employee-sort";
// Die Sortierung steht in der Adresse, und dort kann alles stehen: eine
// veraltete Verknüpfung, ein Tippfehler, ein abgeschnittener Wert. Sie darf
// die Liste weder leeren noch in einer Reihenfolge zeigen, die niemand
// gewählt hat — und schon gar nicht in die Abfrage durchschlagen.
describe("parseSortierung", () => {
it("nimmt jede angebotene Sortierung", () => {
// Aus der Liste abgeleitet, nicht abgeschrieben: käme eine dritte
// Sortierung dazu, prüft dieser Test sie mit, ohne dass jemand daran
// denken muss.
for (const s of SORTIERUNGEN) {
expect(parseSortierung(s.value)).toBe(s.value);
}
});
it("fällt ohne Angabe auf A–Z zurück", () => {
expect(parseSortierung(undefined)).toBe(STANDARD_SORTIERUNG);
expect(parseSortierung("")).toBe(STANDARD_SORTIERUNG);
expect(STANDARD_SORTIERUNG).toBe("az");
});
it("lässt sich nichts unterschieben", () => {
expect(parseSortierung("AZ")).toBe(STANDARD_SORTIERUNG);
expect(parseSortierung("last_name desc")).toBe(STANDARD_SORTIERUNG);
expect(parseSortierung("id; drop table employees")).toBe(STANDARD_SORTIERUNG);
});
});
describe("richtung", () => {
it("dreht nur bei Z–A", () => {
expect(richtung("az")).toBe("asc");
expect(richtung("za")).toBe("desc");
});
it("liefert für jede Sortierung eine gültige Richtung", () => {
// Die Richtung geht unmittelbar in die Abfrage. Ein anderer Wert als
// asc oder desc wäre dort ein Fehler zur Laufzeit, nicht beim Bauen.
for (const s of SORTIERUNGEN) {
expect(["asc", "desc"]).toContain(richtung(s.value));
}
});
});