Ho una libreria che è abbastanza grande ma espone solo una API molto piccola per renderlo facile da usare e da imparare per i nuovi utenti. Vorrei mantenere la mia libreria in questo modo, ma voglio anche assicurarmi di avere il maggior numero di test unitari possibile, vorrei essere in grado di testare direttamente tutte le mie lezioni, ma per quanto posso dire che posso solo l'unità verifica l'API pubblica della libreria.freccetta, unità di test metodi privati
Posso, naturalmente, scrivere test di unità per testare completamente i metodi pubblici che testano in modo efficace indirettamente tutte le classi private sottostanti, ma se un test fallisce potrebbe significare molto scavare nel codice privato per trovare dove qualcosa è andato storto, piuttosto che avere test unitari per ogni singola classe privata, quindi quando qualcosa va storto è immediatamente evidente cosa è andato storto e dove.
Esiste un modello di progettazione per aiutare con questa situazione o un modo per il test delle unità da scrivere per classi e metodi di dart privati?
Stavo pensando di esporre tutti i membri privati estendendo da ognuno una classe di test pubblica che non aggiunge nulla alla classe privata sottostante, in questo modo posso testare direttamente attraverso le classi di test esposte e solo dire agli utenti di ignorare anythign che inizia con "Test", ma questo sembra molto sporco – 0xor1
Puoi dividere la tua libreria in più librerie? Se sposti le tue classi private in una libreria separata nella stessa applicazione, puoi renderle pubbliche e testarle. Dovresti quindi importarli nella tua libreria corrente e non esportarli (quindi l'utente della tua libreria non può ancora usare le tue altre classi se non importa da solo l'altra libreria). –
così semplice il suo genio! – 0xor1