tag:blogger.com,1999:blog-1481755160576909631.post7560480199943808339..comments2009-05-16T20:23:05.090+02:00jcesarperezhttp://www.blogger.com/profile/09407010927256988320julio.cesar.perez.arques@gmail.comBlogger6125tag:blogger.com,1999:blog-1481755160576909631.post-67182119879760580372009-05-16T20:23:00.000+02:002009-05-16T20:23:00.000+02:00Hola Alfredo. Me alegra mucho verte por aquí. No se porqué pensaba que eras tú...<br /><br />Estoy contigo en, por lo general, hacer tests de la parte pública de las clases. Yo iría un poco más allá y diría que los tests deben hacerse principalmente en las clases Service. Así obtienes mayor cobertura y sobretodo no repites tests que luego son costosos de mantener. Como los tests de las clases dao que luego se repiten en las clases service.<br /><br />Lo del protected es bastante radical sí. ¿Tus métodos que convierten los objetos de dominio a dtos y viceversa también son públicos? ¿O lo que haces es que esas clases menos importantes no sean públicas?<br /><br />Por mi parte, coincido también contigo en preferir la composición como mecanismo de reutilización de código frente a la herencia. Pero de ahí a prohibirla... Es cierto que suele abusarse de ella, pero hay ocasiones donde encaja de forma natural. ¿Tampoco usas clases abstractas?<br /><br />Un saludo.jcesarperezhttp://www.blogger.com/profile/09407010927256988320noreply@blogger.comtag:blogger.com,1999:blog-1481755160576909631.post-68755777497544213742009-05-15T21:33:00.000+02:002009-05-15T21:33:00.000+02:00Es buena practica que las clases de test estén en el mismo paquete y distinta carpeta fisica. Pero en mi opinión no para poder hacer pruebas directas sobre metodos protected sino para poder llamar a constructores (o setters aunque esto tampoco me gusta demasiado) donde puedas establecer objetos mock para las interfaces de las que dependa tu clase. Aunque esto usando inyección de dependencias en realidad también se puede resolver, y los test en el mismo paquete terminan siendo simplemente una buena practica porque mantiene el proyecto organizado.<br /><br />En mi opinión los test nunca se deben hacer sobre nada que no sea public, de esta forma los test son independientes de la organización interna de la clase y puedes cambiar esta sin tener que modificar los test.<br /><br />Y otra que a muchos les sonara radical: Nunca usar el modificar protected, esto en realidad deriva de otras dos practicas:<br />- nunca usar herencia de clases (de interfaces si por supuesto) y siempre preferir composición como mecanismo de reutilización.<br />- siempre depender de interfaces y nunca de implementaciones concretas, es decir, ninguna clase depende de nada que no sea un interfaz.<br /><br />Con estas dos normas carece de sentido el uso de protected excepto quiza para algún constructor donde se inyecten dependencias a mano para los test.<br /><br />Llevamos más de un año siendo así de radicales, y estamos muy contentos con el resultado, menor acoplamiento, mayor cohesión , clases con responsabilidades mucho mejor definidas y menos complejas y test que se entienden!! (esto nos mataba antes, test que eran tan complejos que al final eran una pesadilla de mantener).alfredo.casadohttp://www.blogger.com/profile/13846968782016630321noreply@blogger.comtag:blogger.com,1999:blog-1481755160576909631.post-63545080313745849222009-05-14T22:14:00.000+02:002009-05-14T22:14:00.000+02:00Sí, probar metodos privados puede (suele) ser un síntoma de mal diseño. Ya lo decía al principio...<br />Pero a veces no queda otra, como cuando te toca código legacy o simplemente no puedes modificar el código fuente.<br /><br />Lo de los métodos protected sí que no lo comparto. Las clases de tests deben estar en el mismo package que la clase que prueban (pero en diferentes carpetas físicas). De ese modo, la clase de tests tiene visibilidad sobre todos los métodos que no sean private.<br /><br />Podéis ver más sobre buenas prácticas de tests aquí: http://jcesarperez.blogspot.com/2009/04/buenas-practicas-para-programar-tests.htmljcesarperezhttp://www.blogger.com/profile/09407010927256988320noreply@blogger.comtag:blogger.com,1999:blog-1481755160576909631.post-42931970144149776262009-05-14T21:28:00.000+02:002009-05-14T21:28:00.000+02:00No hagais test sobre metodos privados hombre po dios!!<br /><br />Precisamente una de las ventajas de los test unitarios es que ayudan a guiar un buen diseño. Solo se deben probar los metodos públicos, y si probar un metodo publico es muy complejo porque tiene N metodos privados a los que llama entonces es que el código es demasiado complejo y hay que refactorizar en clases más pequeñas y con responsabilidades más concretas.<br /><br />En mi opinión, y se que algunos les sonara radical, es preferible evitar los metodos privados o protected.alfredonoreply@blogger.comtag:blogger.com,1999:blog-1481755160576909631.post-18295770234724440832009-05-14T09:32:00.000+02:002009-05-14T09:32:00.000+02:00Yo lo utilizo en un proyecto interno para sacar un botón por programa y que me ponga el nombre y el tooltip de las propiedades del mismoLekhttp://www.blogger.com/profile/10915147172432652103noreply@blogger.comtag:blogger.com,1999:blog-1481755160576909631.post-67956856409105160922009-05-13T23:28:00.000+02:002009-05-13T23:28:00.000+02:00Gracias por el truco, me parece especialmente útil para hacer tests unitarios directamente sobre métodos privados.<br /><br />Saludosjaronoreply@blogger.com