Desenvolvendo um Framework com TDD - Um Diário de Bordo - Agile Trends 2014
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 510 views

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 ...

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.

Statistics

Views

Total Views
510
Views on SlideShare
504
Embed Views
6

Actions

Likes
3
Downloads
3
Comments
0

1 Embed 6

https://twitter.com 6

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • Journey's Diary Developing a framework using TDD Eduardo Guerra
    • The Framework Case Study
    • http://bit.do/tddframework
    • INTERFACE INTERFACE + name conventions + anotations + entity class structure Query Builder Dynamic Proxy Framework
    • DSL INTERFACE + name conventions + anotations + entity class structure
    • QueryBuilder Core QueryBuilder JPA QueryBuilder MongoDB QueryBuilder JDBC QueryBuilder Neo4J
    • For a good understander, the method name is enough!
    • 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.
    • That is the question! To mock orTo mock or not tonot to mock?mock?
    • What should I do when I have things that are hard to test, like external resources? MOCK
    • Why? It will make the test difficult Test will be coupled with external APIs It can make the test slow
    • But should I mock the external APIs themselves? MOCK
    • 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
    • What should I do when I have classes that are not exposed to the class clients? MOCK
    • 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
    • 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?
    • 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
    • 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.
    • Unit or Integration ?Unit or Integration ? Can I use both on TDD?Can I use both on TDD?
    • 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.
    • 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 =
    • If I'm defining my design using tests, when can I use integration tests?
    • Easy question! When your design is already defined!
    • Class A Class B Class C Imagine that an architecture with these three classes
    • 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
    • Class A Class B Class C INTEGRATION TEST Now that everything is defined, you can use integration tests to develop Class B using TDD.
    • 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!
    • QueryExecutor QueryBuilder QueryVisitor QueryBuilder TESTED TESTED Since the other classes are already tested, QueryExecutor was developed using integration tests.
    • Big RefactoringsBig Refactorings They will happen!They will happen!
    • 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!
    • 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.
    • If that happens, STOP and refactor your solution!
    • QueryBuilder method call process write query method call process write query storerefactor When appear a requirement where the processing depends on the next call...
    • Final ConsiderationsFinal Considerations What isWhat is missing?missing?
    • 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.
    • SophisticatedSophisticated solutionssolutions sometimessometimes are the betterare the better ones for theones for the problem.problem. Don't avoid them!Don't avoid them!
    • You can use TDD only for development, or also as a design technique. If you choose design you can not avoid mocking!
    • @Test public void presentationEnd(){ Presentation p = new Presentation(); Audience a = new Audience(); p.setAudience(a); p.perform(); p.end(); p.thanksEveryone(); assertTrue(a.isApplauding()); }