Attualmente lavoro su un progetto per hobby che uso per saperne di più sulla programmazione e la programmazione Android / Java in generale. Recentemente, ho deciso di integrare jUnit nel progetto. Il solo fatto di averlo inserito non era un grosso problema, ma in realtà lo stava usando. Ho letto che un test unitario dovrebbe essere la definizione di ciò che un metodo (o componente) dovrebbe fare, e che i test di unità ti costringono a scrivere codice buono, o almeno migliore.
Ma i problemi iniziarono a verificarsi nel momento in cui scrissi il primo test unitario per testare qualche logica. Il metodo che volevo testare è solo un lavoro logico, nulla con l'interfaccia utente è stato fatto e i risultati vengono semplicemente salvati in variabili per un uso successivo. Ma, nella stessa classe, ho un metodo per visualizzare qualsiasi cosa abbia funzionato il primo metodo. E a JUnit non sembra piacere; per il secondo metodo ho bisogno (ovviamente) di importare UI, e jUnit lamenta che non conosce alcuna "classe Context Android". Fino ad ora, ho pensato che mettere le parti logiche e dell'interfaccia utente di un componente in una classe, ma i metodi separati sarebbe facilmente comprensibile e una pratica accettabile. Ma ora, perché "jUnit ti costringe a scrivere un buon codice", ne sono molto meno sicuro.
Quindi, dovrei inserire l'interfaccia utente e le parti logiche per un componente in classi separate? Esse dipendono l'una dall'altra, il metodo UI ha bisogno dei valori del metodo logico, ma il metodo logico non può fare nulla con i suoi valori calcolati senza il metodo UI. Ma perché qualcun altro potrebbe pensarla diversamente ... E quel "qualcun altro" è quello che probabilmente dovrà capire il mio codice dopotutto.