En sandlåda med påhittad data slår en kopia av produktionen

I varje litet teams liv kommer en stund då någon föreslår att den lokala utvecklingen ska peka mot en kopia av produktionsdatabasen, för att testdatan känns tunn och de riktiga buggarna bara uppstår med riktiga poster. Det är en lockande idé med en lång svans av ånger: inloggningsuppgifter spridda över laptops, kundnamn i skärmbilder, ett testutskick som en dag hittar riktiga adresser. Vi gick åt andra hållet och har aldrig ångrat det.

En hel Postgres inuti processen

Inbäddade Postgres-byggen har blivit riktigt bra. Vår app bestämmer vid start: finns riktiga databasuppgifter i miljön används den hostade databasen, är de tomma startas en Postgres i samma process som ligger i en lokal mapp. Utvecklingsdatorer har helt enkelt aldrig uppgifterna, så det värsta som händer med en felkonfigurerad laptop är en ny tom databas, inte en incident i produktionen.

1// Choose the database at runtime. Blank env = embedded, local, harmless.2function makeDb() {3  const url = process.env.DATABASE_URL;4  if (url) return connectHosted(url);5  // In-process Postgres persisted to a local folder6  const client = new EmbeddedPostgres('./.pgdata');7  return drizzle(client, { schema });8}

Hur databasen byggs om spelar lika stor roll som motorn. Vi återskapar den lokala databasen genom att köra samma migrationsfiler som produktionen körde, i ordning, från den första. Det enda beslutet har fångat en hel familj av buggar gratis: en migration som förutsatte en kolumn från en senare fil, en schemaändring som fungerade mot en gammal ögonblicksbild men inte från noll. Kan laptopen inte bygga schemat ur historiken, kunde nästa driftsättning inte heller det.

Skapa ett företag, inte rader

Skillnaden mellan oanvändbar och användbar testdata är att den berättar något. Vårt seed-skript lägger inte in tio användare som heter test. Det skapar en salong med ett namn, personal med specialiteter, tjänster med ärliga priser och tider, kunder med besökshistorik, kommande bokningar, butiksprodukter med lagersaldon och en huvudbok bakom sig. Sidorna ser bebodda ut, vilket gör att buggar i layouten, tomma lägen och klumpiga avhuggningar dyker upp precis som de skulle göra för en riktig kund.

Den sista egenskapen är lätt att underskatta. Varje skärmbild i vår dokumentation, vår blogg och våra buggrapporter kommer från sandlådan. Ingen behöver kisa på en bild och undra om ett kundnamn slank med, för det finns inga kundnamn som kan slinka med. Den säkraste maskningen är att inte ha något att maska.

Det som måste bli rätt

• Gör den säkra vägen till standardvägen. Utvecklare ska behöva anstränga sig för att nå riktig data, inte för att undvika den.
• Neutralisera sidoeffekterna också: nycklar för e-post, betalningar och lagring är tomma lokalt, så en slinga över påhittade kunder kan aldrig skicka något till en riktig person.
• Fyll på med de lägen du bävar för: det helt nya kontot, den fullbokade dagen, produkten som är slut, kunden med ett enda besök för flera år sedan.
• Låt seed-skriptet ingå i kodgranskningen. När en funktion lägger till en tabell växer skriptet med den, annars ruttnar sandlådan i tysthet.

Vinsten växer med tiden. Nya kollegor kör två kommandon och har ett fungerande företag att peta på. Visuell testning kan fotografera varje sida utan en integritetsgranskning. Och demomiljön är alltid fem minuter från nyskick, för nyskick är bara en ombyggnad bort.

Produktionsdata svarar på frågor. Påhittad data låter dig ställa dem tryggt.