TDD per applicazione grafica

Dipende da cosa sta facendo il tuo codice, cioè qual è la logica effettiva che devi testare.

Presumo che la tua applicazione utilizzi un'API per disegnare oggetti come cerchi, linee, ecc. In questo caso, l'obiettivo non è verificare se l'immagine / schermo corrisponde a quanto previsto, se hai richiesto l'API per disegnare un cerchio in una data posizione, appartiene a quell'API per riflettere l'immagine / lo schermo di conseguenza. Invece, ciò che devi testare è che quando un chiamante ha richiamato un metodo specifico di tuo codice, allora il tuo codice ha chiamato un metodo per disegnare questo o quello.

Fai questo usando falsi o motti. In altre parole, quando si verifica una classe specifica, non si inietterà la vera API che disegna gli oggetti su un'immagine / schermo, ma invece un sostituto che si è scritto specificamente per i test e che non farà alcun disegno reale. Invece, il sostituto solo, per esempio, registrerà che hai chiamato un determinato metodo con parametri specifici. Successivamente, il test richiederà questo sostituto per stabilire se il metodo è stato chiamato, e ha esito positivo o negativo a seconda di quello.

Quando le persone usano il termine "Test Driven Development" si presume spesso che stiano parlando di codice di test unitario. Ma ci sono altri tipi di test che puoi usare per guidare il tuo sviluppo.

Se vuoi fare confronti tra immagini per i test, è certamente possibile farlo. Ci sono misure come la deltaE differenza di colore che può essere usata per dire se un'immagine generata dal tuo codice è cambiata da una corsa all'altra Il prossimo.

Non vorresti eseguirli come test unitari che sono tradizionalmente eseguiti prima di ogni build, per esempio. Ma potresti eseguirli dopo ogni commit al tuo repository di origine, o una volta a notte come parte del tuo sistema di integrazione continua.

Dove lavoro, abbiamo utilizzato con successo questi test per tenerci informati sulle regressioni di rendering, sugli errori di rendering o su altre modifiche e differenze visive che potremmo voler sapere. Non è semplice come scrivere un test unitario per vedere se il tuo codice gestisce un caso limite particolare, ma può essere molto utile per capire come le modifiche al codice influenzano il rendering.