2015-01-16 15 views

risposta

20

Quando si utilizza #[test], non c'è nulla di speciale nei metodi privati ​​o pubblici: si scrive semplicemente perfettamente le funzioni normali che possono accedere a qualsiasi cosa a cui possono accedere.

fn private_function() { 
} 

#[test] 
fn test_private_function() { 
    private_function() 
} 

test esterni, come ad esempio tests/*.rs e examples/*.rs se si sta utilizzando merci, o prove doc, non si ottiene l'accesso ai membri private; né dovrebbero: questi test sono progettati per essere test API pubblici, per non trattare i dettagli dell'implementazione.

+0

I test esterni devono assolutamente consentire l'accesso alle parti private, perché 1) Potrebbe essere necessario accedere a parti private per attivare in modo affidabile tutti i percorsi di codice tramite l'API pubblica. Ad esempio, potrebbe esserci una soglia interna che, una volta raggiunta, attiva un percorso di codice diverso. Potresti anche aver bisogno di un'iniezione fallita o di dettagli interni per attivare casi limite. 2) L'accesso alle parti private può fornire una diagnostica migliore per quando i test falliscono - è possibile inserire informazioni interne nel messaggio di panico ecc ... – kralyk

+0

Diagnostics: questo è ciò che 'std :: fmt :: Debug' è per. Per il resto, sostengo la mia posizione secondo cui i test esterni non dovrebbero avere accesso ai dettagli privati. I test esterni non sono appropriati per la situazione che descrivi: ecco a cosa servono i test delle unità interne. –

+0

'fmt :: Debug' è troppo voluminoso in alcune situazioni: ad esempio, potresti non voler stampare i dettagli di un'intera enorme struttura dati quando sei solo dopo un determinato bit. Ad ogni modo, è appropriato che il test interno configuri anche un caso di utilizzo realistico dell'API pubblica? Altrimenti, non lo farò, visto che ho bisogno di fare proprio questo. Se sì, allora va bene sono contento di tutto ciò e dei test interni, anche se a quel punto la distinzione è un po 'inutile? Il problema principale è che, indipendentemente da quanto ci provi, i dettagli dell'implementazione influenzano sempre l'interfaccia in qualche modo, non c'è modo di aggirarla. – kralyk

Problemi correlati