Voglio testare un metodo statico di tipo UtilsClass, che restituisce uno . All'interno di questo metodo, inserisco una coppia di String [] nel suo costruttore, ad es. final Pair<String[], String[]> pair = new Pair<>(new String[] {"Hello", "World"}, new String[] {"£33", "£44"}); e si aspetta che questo oggetto venga restituito.android.util.Pair contiene String [] come parametri in AndroidTest ma null in (unit) test
Quando provo questo metodo, ottengo un oggetto Pair non nullo ma con i suoi campi first = null e second = null. Quando eseguo lo stesso codice di test in un test di tipo Instrumentation, i campi vengono popolati correttamente. Posso vedere che in quest'ultimo caso, il costruttore public Pair(F first, S second) { dove inserisco il punto di debug è inserito e campi impostati, ma non in Test unità.
Sto cercando una spiegazione del motivo per cui questo sarebbe il caso, e se dovessi evitare di passare il String[] come parametri del costruttore nel codice in primo luogo.
test di unità può utilizzare oggetti fittizi che sono fondamentalmente no-ops. Durante il debug, puoi entrare nel costruttore e vedere cosa succede realmente. È possibile che il costruttore della classe che viene utilizzata sia effettivamente vuoto – njzk2
Questo sembra essere il caso! Quando ho usato il metodo di convenienza 'public static Pair create (A a, B b) {' invece ho ottenuto l'errore "" Metodo ... non deriso. "". La rotazione dei valori reali nel test ha rimosso l'errore, ma i valori in entrambi i metodi di creazione erano ancora nulli. android.support.v4.util.Pair non ne risente affatto. –
TomaszRykala
Sì, poiché il supporto è una libreria, è in bundle con il tuo apk comunque (quindi non può essere deriso dal test dell'unità) – njzk2