Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Desenvolvendo um Framework com TDD - Um Diário de Bordo - Agile Trends 2014


Published on

Essa apresentação é um relato de experiência a respeito da utilização do Test-driven Development (TDD) para o desenvolvimento do framework Esfinge QueryBuilder. Serão abordadas questões práticas e lições aprendidas durante esse desenvolvimento, focando em como trabalhar em um design complexo utilizando TDD. Algumas das questões abordadas serão: quando utilizar mock objects, como reduzir o esforço com a codificação dos testes, quando utilizar testes de integração e como fazer grandes refatorações. Cada tópico será ilustrado com exemplos reais ocorridos durante o desenvolvimento do framework.

Published in: Technology, Education
  • Be the first to comment

Desenvolvendo um Framework com TDD - Um Diário de Bordo - Agile Trends 2014

  1. 1. Journey's Diary Developing a framework using TDD Eduardo Guerra
  2. 2. The Framework Case Study
  3. 3.
  4. 4. INTERFACE INTERFACE + name conventions + anotations + entity class structure Query Builder Dynamic Proxy Framework
  5. 5. DSL INTERFACE + name conventions + anotations + entity class structure
  6. 6. QueryBuilder Core QueryBuilder JPA QueryBuilder MongoDB QueryBuilder JDBC QueryBuilder Neo4J
  7. 7. For a good understander, the method name is enough!
  8. 8. public List<Person> getPersonByNameOrAge (String name, int age); Using a simple naming pattern, you can define the entity and the properties to be used as filters.
  9. 9. That is the question! To mock orTo mock or not tonot to mock?mock?
  10. 10. What should I do when I have things that are hard to test, like external resources? MOCK
  11. 11. Why? It will make the test difficult Test will be coupled with external APIs It can make the test slow
  12. 12. But should I mock the external APIs themselves? MOCK
  13. 13. Why not? Create a class that encapsulates the access to this API! It is a perfect match on the class needs The API can be hard to mock Decouple the class from the API
  14. 14. What should I do when I have classes that are not exposed to the class clients? MOCK
  15. 15. Why not? The solution can't be refactored without changing the test Class don't need to be exposed Test will be coupled to the solution
  16. 16. What should I do when my class have a hotspot or a dependence with variable behavior? MOCK What should I do when my class have a hotspot or a dependence with variable behavior?
  17. 17. Why? Mock can explore all possibilities, such possible errors Mock can be used to divide class responsibilities Mock can be used to design the dependence API
  18. 18. QueryBuilder MethodParser Visitor that generates the query was mocked because it is a hotspot. MOCK MOCK A composite to store query parameters was not mocked because it is an internal solution.
  19. 19. Unit or Integration ?Unit or Integration ? Can I use both on TDD?Can I use both on TDD?
  20. 20. Unit Test decouplingdecoupling = Creating unit tests you areCreating unit tests you are dividing responsibilities and definingdividing responsibilities and defining the interaction among the classes.the interaction among the classes.
  21. 21. You are having feedback on yourYou are having feedback on your implementation, but it is notimplementation, but it is not helping to define your design.helping to define your design. Integration Test black boxblack box =
  22. 22. If I'm defining my design using tests, when can I use integration tests?
  23. 23. Easy question! When your design is already defined!
  24. 24. Class A Class B Class C Imagine that an architecture with these three classes
  25. 25. Class A Class C MOCKUNIT TEST Developing Class A, the services needed from Class B were defined. Class C interface were defined on its own TDD session. UNIT TEST
  26. 26. Class A Class B Class C INTEGRATION TEST Now that everything is defined, you can use integration tests to develop Class B using TDD.
  27. 27. If you designed everything upfront, youIf you designed everything upfront, you don't need TDD as adon't need TDD as a designdesign technique!technique!
  28. 28. QueryExecutor QueryBuilder QueryVisitor QueryBuilder TESTED TESTED Since the other classes are already tested, QueryExecutor was developed using integration tests.
  29. 29. Big RefactoringsBig Refactorings They will happen!They will happen!
  30. 30. When you always search for theWhen you always search for the simplest solution, sometimessimplest solution, sometimes you reach a dead end!you reach a dead end!
  31. 31. However, most of the time theseHowever, most of the time these problems are concentrated on a singleproblems are concentrated on a single class and isolated from the others.class and isolated from the others.
  32. 32. If that happens, STOP and refactor your solution!
  33. 33. QueryBuilder method call process write query method call process write query storerefactor When appear a requirement where the processing depends on the next call...
  34. 34. Final ConsiderationsFinal Considerations What isWhat is missing?missing?
  35. 35. You still have to knowYou still have to know patterns to understand the solutionpatterns to understand the solution that you are driving through the tests.that you are driving through the tests.
  36. 36. SophisticatedSophisticated solutionssolutions sometimessometimes are the betterare the better ones for theones for the problem.problem. Don't avoid them!Don't avoid them!
  37. 37. You can use TDD only for development, or also as a design technique. If you choose design you can not avoid mocking!
  38. 38. @Test public void presentationEnd(){ Presentation p = new Presentation(); Audience a = new Audience(); p.setAudience(a); p.perform(); p.end(); p.thanksEveryone(); assertTrue(a.isApplauding()); }