Je n’écris pas de tests unitaires. Je comprends le principe, mais je n’y adhère pas. J’ai 0 tests,
Prioriser le static, le plus possible. Si quelque chose est polyvalent pour tout le code, et n’a pas besoin d’être libéré/détruit alors il sera static.
Eviter les get/set de vos variables privés (sauf dans le cas ou vous avez besoin de faire un check en entrée ou une transformation en sortie) et remplacez les get/set par un accès direct à la variable.
Design pattern : c’est indispensable d’en connaître quelqu’uns ou au moins de connaître quelques principes.
Avancer pas à pas sur de bonnes bases mais abstraire ce qu’il faut
...
C’est notamment ça le travail « d’architecte logiciel » que je parlais plus tôt.
Et un jour tu découvriras le TDD, tu feras en sorte d'écrire du code testable depuis le début, tu deviendras test infected et les notions d'emergent design tu embrasseras et le surdesign tu éviteras ... naturellement
# Les tests
Posté par El Titi . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 9.
Et un jour tu découvriras le TDD, tu feras en sorte d'écrire du code testable depuis le début, tu deviendras test infected et les notions d'emergent design tu embrasseras et le surdesign tu éviteras ... naturellement
Petit florilège de liens:
Le singleton c'est le mal:
http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons
Les methodes static sont un antipattern:
http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/
du bon usage du privé avec les tests:
http://programmers.stackexchange.com/questions/100959/how-do-you-unit-test-private-methods
Tu découvriras d'abord Powermock et tu comprendras que plus on dépend de framework plus on se rajoute de la dette technique.
Et tu concevras ton code pour éviter ces pièges et tu atteindras le level "Classic TDDist" en utilisant les bons types de doublures dans ton code et en n'utilisant le petit frère Mockito qu'à bon escient:
http://martinfowler.com/articles/mocksArentStubs.html
http://coding-is-like-cooking.info/2013/04/the-london-school-of-test-driven-development/
Puis tu accéderas au nirvana en t'imprégnant de l'emergent design:
http://www.ibm.com/developerworks/library/j-eaed2/
http://www.aniche.com.br/wp-content/uploads/2013/04/asq-tdd.pdf
Puis dans le DDD (http://www.infoq.com/articles/ddd-in-practice) tu flotteras et l'anemic domain model (inhérent à cretain frameworks) tu exécreras (http://www.martinfowler.com/bliki/AnemicDomainModel.html)
Bon cheminement
Et pour conclure ton billet était intéressant