From CBSoft 2012 Industry Trail

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

2. Case Study
The Framework

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

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

5. QueryBuilder JPA
QueryBuilder MongoDB
QueryBuilder Neo4J
QueryBuilder
Core
QueryBuilder JDBC

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

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

8. public List<Person>
getPersonByNameOrAge
(String name, int age);
The return type indicates if you
expect a single or multiple results.
public Person
getPersonByNameOrAge
(String name, int age);

9. public List<Person>
getPersonByNameOrAge
(String name, int age);
It is verified if the
parameter types matches
the property types.

10. public List<Order>
getOrderPendingByDateGreater
(Date date);
Anotations or conventions can
be used to define the filter type.
public List<Order>
getOrderPendingByDate
(@Greater Date date);

11. You can define new domain
terms and use them on the
method names.
@DomainTerm(term=“pending“
conditions = @Condition(
property=”status”, value=”P”))
public List<Order>
getOrderPendingByDate
(@Greater Date date);

12. public List<Person> getPerson
(@QueryObject PersonSearch p);
For complex queries, you
can define a class with
the filters and metadata
about how they should be
handled.

13. public List<Person>
getPersonByNameAndLastName
(@CompareToNull String name,
@IgnoreWhenNull String lastname);
You can configure the
query to compare to null
or to ignore when the
parameter is null.

14. Tests
They
consume my
development
time?

15. YES
on the begining...

16. In the first tests, you
usually need more effort to
create scenarios and verify
the expect results.
● Create mocks
● Handle external
resources
● Do complex
verifications

17. On the next tests, the code
created is reused and the
time to introduce a new test
for the TDD cycle is very small.

18. Tips
Put common things in setup
Create helper methods
Create test superclasses
Search for the right framework

19. QueryBuilder
MethodParser
Some MethodParser mocks
were defined on setup and
used on all tests.

20. QueryBuilder
ClassMock
Framework
ClassMock were used to
generate classes in
runtime to test reflection.

21. To mock or
not to
mock?
That is the question!

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

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

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

25. Why not? Create a class that
encapsulates the
access to this API!
Decouple the class from the API
It is a perfect match on the
class needs
The API can be hard to mock

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

27. Why not?
Test will be coupled to the
solution
The solution can't be refactored
without changing the test
Class don't need to be exposed

28. What should I do when my
class have a hotspot or a
dependence with variable
behavior?
MOCK

29. Why?
Mock can be used to design the
dependence API
Mock can explore all possibilities,
such possible errors
Mock can be used to divide class
responsibilities

30. Visitor that
generates the query
was mocked because
QueryBuilder it is a hotspot.
MOCK
MethodParser
MOCK
A composite to store query
parameters was not mocked
because it is an internal solution.

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

32. Unit Test
=
decoupling
Creating unit tests you are
dividing responsibilities and defining
the interaction among the classes.

33. Integration Test
= box
black
black box
You are having feedback on your
implementation, but it is not
helping to define your design.

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

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

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

37. Developing Class A, the services needed
from Class B were defined.
Class A
UNIT TEST MOCK
Class C interface were defined on its
own TDD session.
Class C
UNIT TEST

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

39. If you designed everything upfront, you
don't need TDD as a design technique!

40. ESTED
T
QueryBuilder QueryBuilder
Since the other
classes are already
tested, QueryExecutor QueryExecutor
was developed using
integration tests.
ESTED
T
QueryVisitor

41. Big Refactorings
They will happen!

42. When you always search for the
simplest solution, sometimes
you reach a dead end!

43. However, most of the time these
problems are concentrated on a single
class and isolated from the others.

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

45. method call
QueryBuilder
method call refactor store
When appear
a requirement
process process
where the
processing
depends on
the next call...
write query write query

46. Final Considerations
What is
missing?

47. You still have to know patterns to
understand the solution that you are
driving through the tests.

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

49. Refactoring is a
very important
design tool!

50. Using TDD you
finish the
session very
proud of your
work!

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