Mi è stato detto dal mio capo di usare Moq e basta. Mi piace ma sembra che a differenza di MSTest o mbunit ecc ... non è possibile testare i metodi interniMoq come si testano i metodi interni?
Quindi sono costretto a rendere pubblica qualche implementazione interna nella mia interfaccia in modo da poterla testare.
Mi manca qualcosa?
È possibile verificare i metodi interni utilizzando Moq?
Grazie mille
È possibile utilizzare l'attributo InternalsVisibleTo per rendere i metodi visibili a Moq.
Per gli assembly con un nome sicuro, è necessario. [assembly: InternalsVisibleTo ("DynamicProxyGenAssembly2, PublicKey = 0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")] –
Se si dispone di molti codice che non è testato dai metodi pubblici, probabilmente avere il codice che deve essere spostato in un altro classi.
Come detto in un'altra risposta, è possibile utilizzare l'attributo InternalsVisibleTo per quello. Ma questo non significa che dovresti farlo.
non è il punto di unit testing per testare tutto però? Testare i metodi interni/privati potrebbe rivelare problemi con quelli pubblici. Soprattutto quando si aggiungono nuove funzioni pubbliche e si usano quelle interne ... o mi manca qualcosa? – CodeRedick
La presunzione iniziale che sia necessario testare il metodo interno è un malinteso comune sui principianti riguardo ai test unitari.
Concesso, possono esistere casi in cui i metodi privati devono essere testati isolatamente, ma il caso comune del 99% è che i metodi privati vengono testati implicitamente perché fanno sì che i metodi pubblici superino i test. I metodi pubblici chiamano i metodi privati.
I metodi privati ci sono per un motivo. Se non comportano un comportamento testabile esterno, non ne hai bisogno.
I test pubblici falliscono se si eliminano completamente? Se sì, allora sono già stati testati. Se no, allora perché ne hai bisogno? Scopri quello che ti serve e poi esprimilo in un test contro l'interfaccia pubblica.
Un vantaggio principale con TDD è che il codice diventa facile da modificare. Se inizi a testare internals, il codice diventa rigido e difficile da modificare.
Non c'è niente di sbagliato nel rendere gli interni visibili ad altre classi per il test. Se è necessario testare i componenti interni di una classe, farlo assolutamente. Solo perché i metodi non sono pubblici non significa che dovresti ignorarli e testare solo quelli pubblici. Un'applicazione ben progettata in realtà avrà la maggior parte del codice incapsulato all'interno delle classi in modo tale da non essere pubbliche. Quindi ignorare i metodi non pubblici nei test è un grosso errore IMHO. Una delle bellezze dei test unitari è che testate tutte le parti del vostro codice, non importa quanto siano piccole e quando i vostri test sono tutti operativi al 100%, è un'ipotesi molto ragionevole che quando tutte queste parti sono unite, il vostro l'applicazione funzionerà correttamente per l'utente finale. Naturalmente verificando che la seconda parte è il luogo in cui i test di livello di integrazione entrano - che è una discussione diversa. Quindi prova via !!!
InternalsVisibleTo è il tuo amico per i test interni. Ricordati di firmare le tue assemblee e sei al sicuro.
Dal mio punto di vista, il mocking deve essere utilizzato per prendere in giro alcuni comportamenti da cui dipendiamo ma che non si stanno tentando di testare. Quindi:
D: Mi manca qualcosa? - No non ti manca nulla, MOQ manca la capacità di deridere i comportamenti privati.
D: È possibile testare i metodi interni utilizzando Moq? - Se il risultato del comportamento privato è visibile pubblicamente, allora sì puoi testare il metodo interno ma non è a causa di Moq che puoi testarli. Vorrei sottolineare che Mock non è la capacità di testare, ma piuttosto la capacità di comportamenti simili che non stiamo testando, ma da cui dipendiamo.
C: Un vantaggio principale con TDD è che il codice diventa facile da modificare. Se inizi a testare internals, il codice diventa rigido e difficile da modificare - Non sono d'accordo con questo commento per 2 ragioni principali: 1: Non è un equivoco principiante, dato che TDD non riguarda solo la capacità di codificare codice di qualità più veloce ma anche migliore. Quindi più test possiamo fare meglio. 2: Non rende più difficile modificare il codice se è possibile in qualche modo testare i metodi interni.
Moq non è un'alternativa a MSTest o mbunit. sono entrambi framework di testing unitario, mentre Moq è un framework beffardo. sebbene quasi sempre usati in congiunzione, sono due cose molto diverse. btw +1 al tuo capo, Moq è eccellente ;-) –