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.

1. Journey's Diary
Developing
a framework
using TDD
Eduardo Guerra

2. The Framework
Case Study

3. http://bit.do/tddframework

4. INTERFACE
INTERFACE
+ name conventions
+ anotations
+ entity class structure
Query
Builder
Dynamic
Proxy Framework

5. DSL
INTERFACE
+ name conventions
+ anotations
+ entity class structure

6. QueryBuilder
Core
QueryBuilder JPA
QueryBuilder MongoDB
QueryBuilder JDBC
QueryBuilder Neo4J

7. For a good
understander, the
method name is
enough!

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.

11. That is the question!
To mock orTo mock or
not tonot to
mock?mock?

12. What should I do when
I have things that are
hard to test, like
external resources?
MOCK

13. Why?
It will make the test difficult
Test will be coupled with
external APIs
It can make the test slow

14. But should I mock
the external APIs
themselves?
MOCK

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

16. What should I do when
I have classes that are
not exposed to the
class clients?
MOCK

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

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

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

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

21. Unit or Integration ?Unit or Integration ?
Can I use both on TDD?Can I use both on TDD?

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

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

24. If I'm defining my
design using tests,
when can I use
integration tests?

25. Easy question!
When your
design is already
defined!

26. Class A Class B Class C
Imagine that an
architecture
with these three
classes

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

28. Class A Class B Class C
INTEGRATION
TEST
Now that everything
is defined, you can
use integration tests
to develop Class B
using TDD.

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

30. QueryExecutor
QueryBuilder
QueryVisitor
QueryBuilder
TESTED
TESTED
Since the other
classes are already
tested, QueryExecutor
was developed using
integration tests.

31. Big RefactoringsBig Refactorings
They will happen!They will happen!

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

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

34. If that happens,
STOP and
refactor your
solution!

35. QueryBuilder
method call
process
write query
method call
process
write query
storerefactor
When appear
a requirement
where the
processing
depends on
the next call...

36. Final ConsiderationsFinal Considerations
What isWhat is
missing?missing?

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

38. SophisticatedSophisticated
solutionssolutions
sometimessometimes
are the betterare the better
ones for theones for the
problem.problem.
Don't avoid them!Don't avoid them!

39. You can use TDD only for
development, or also as a
design technique.
If you choose design
you can not avoid
mocking!

40. @Test
public void presentationEnd(){
Presentation p = new Presentation();
Audience a = new Audience();
p.setAudience(a);
p.perform();
p.end();
p.thanksEveryone();
assertTrue(a.isApplauding());
}