I dispositivi di test dovrebbero essere aggiunti ai repository di codice?

Assolutamente sì. Chiunque dovrebbe essere in grado di eseguire i test unitari portandoli fuori dal repository. Qualsiasi automazione di build richiederà questo (dovrebbe, comunque), come lo saranno i futuri sviluppatori.

Un'alternativa potrebbe essere quella di mettere un blocco pre-test nel test dell'unità che controlla i file e li scarica se non ci sono. In questo modo è facile aggiornarli se l'API cambia, e chiunque riceva il codice sarà in grado di eseguirlo senza scavare attorno alla tua macchina per trovare i file mancanti.

Come ha sottolineato Guy, è improbabile che la compressione dei file aiuti - tra la cache dell'SSD / disco e la compressione git di cose che quasi sicuramente non vedremo aumentare la velocità. Con grandi blocchi di dati statici, potrebbe essere sensato collocare un wrapper gz attorno a loro (o simile) per accelerare il caricamento se è facile farlo nella tua lingua. Ciò spinge la dimensione verso il basso, e con dati abbastanza statici nuovi commit (e conseguenti diff) saranno molto rari.

A meno che tu non stia parlando di terabyte di dati (che non credo che tu sia qui), allora lo metterei nel controllo del codice sorgente. Vuoi davvero tutto nella tua soluzione di controllo del codice sorgente in modo che chiunque possa controllarlo ed eseguire l'intera suite di test senza richiedere l'aggiunta di altre dipendenze.

Inoltre, non comprimerei i dati poiché molti sistemi di controllo del codice sorgente forniscono già una compressione dietro le quinte e, se non il sistema di controllo del codice sorgente, il supporto su cui lo memorizzi può fornire la compressione. La ragione per cui in genere non comprimere i dati è che ci sono momenti in cui vorrete cambiare i dati e vorrete essere in grado di fare una differenza tra diverse versioni. Dì che i dati restituiti dalle modifiche API. Questa è una buona ragione per cambiare i dati del dispositivo.

Li assegnerei a qualche tipo di repository, sì.

Non ha bisogno di essere il repository principale, ma tu vuoi preservare lo sforzo che hai messo nella creazione degli apparecchi in primo luogo. Allo stesso modo, se qualcun altro lavora al progetto con te, quindi essere in grado di controllare quegli apparecchi li salverà un sacco di tempo.