This document discusses refactoring test code to improve its design and maintainability without changing its behavior. It defines test code elements like test methods, classes, and suites. It presents refactorings for each element like decomposing assertions, joining similar tests, and mirroring the production code hierarchy. It explains why test smells emerge and how automating refactorings and behavior verification could help future test code refactoring. The goal is to evolve test code design along with production code design while keeping tests easy to maintain and their behavior intact.

1. Refactoring
Test Code
Eduardo Guerra

2. Refactoring
Cleaning the source code to
improve its design without
changing its external
behavior.

3. Source code is simple to
understand and can
address only the current
requirements.
It is easier to maintain and
evolve a simple and
organized code structure.

4. But, does
test code
need to be
refactored?

5. To add or change
functionality you need to
deal with existing tests!

6. “.. keep it (tests) at good object-
oriented design, so than if we need
to make a change or add something
or kick something away , we only
have to do that in may be one place
and not in two hundred different
scripts.“
Lisa Crispin
Author of “Agile Testing“
Software Engineering Radio Podcast

7. How can I
How can I
verify
define what is
maintainance
the test code
of test code
behavior?
behavior?

8. Undestanding
Tests

9. Test Target → instance used
A in the test.
Action → changes environment
or the Test Target.
Assertion → comparison
between the Test Target behavior
and the expected one.

10. Test → a sequence
of at least one action
and one assertion.
A A

11. A A
A A
A A A
Test Suite → a set of tests that
can be independently executed.

12. A A
A A
A A A
Initialization Finalization

13. Verification → a sequence
of actions and one assertion
dealing with the same target.
A A A A
A A A A A
V1 V2

14. Two test suites can be
considered equivalent
when they perform the
same verifications!

15. A A
A A
A A A A
Equivalent! Same Verifications!
A A A
A A A A
A A A A

16. Test Refactoring
Classification

17. Test Method
Test Class
Test Suite

18. Test Method
Refactorings
Changes actions and
assertions for
equivalent ones.

19. Test Method
Refactorings
● Add Assertion Explanation
● Introduce Assertion Method
● Simplify Test Scenario
● Separate Action from Assertion
● Decompose Assertion

20. Decompose
Assertion
@Test @Test
public void needyEmployee{ public void needyEmployee{
Employee e = new Employee(); Employee e = new Employee();
e.setPayment(300); e.setPayment(300);
assertTrue(“Employee Profile”, assertTrue(“Needy employee”,
e.isNeedy() && e.isNeedy());
e.getDiscount() == 0); assertEquals(“Employee is free”,
} e.getDiscount(), 0);
}

21. Test Class
Refactorings
Reorganize actions
and assertions
among methods in
the same test class.

22. Test Class
Refactorings
● Add Fixture
● Introduce Initialization Method
● Inline Initialization Method
● Join Incremental Tests
● Split Test
● Join Similar Tests with
Distinct Data

23. Join Incremental
@Test public void oneItem(){
cart.addItem(100);
assertEquals(115,cart.total());
}
Tests
@Test public void twoItens(){
cart.addItem(100);
cart.addItem(100);
assertEquals(200, cart.total());
}
@Test public void threeItens(){
cart.addItem(100);
cart.addItem(100);
cart.addItem(100);
assertEquals(385, cart.total());
}
@Test public void insertItens(){
cart.addItem(100);
assertEquals(115,cart.total());
cart.addItem(100);
assertEquals(200, cart.total());
cart.addItem(100);
assertEquals(385, cart.total());
}

24. Test Suite
Refactorings
Reorganize test
methods among the
test classes.

25. Test Suite
Refactorings
● Mirror Hierarchy to Tests
● Pull Up Test
● Pull Down Test
● Create Template Test
● Split Tests from Composition

26. <<abstract>>
SuperClass
+methodSuper()
Mirror Hierarchy
TestSubClass2
SubClass2
to Tests
+testMethodSuper()
+methodSub2()
+testMethodSub2()
TestSubClass1 SubClass1
+testMethodSuper() +methodSub1()
+testMethodSub1()
<<abstract>> <<abstract>>
TestSuperClass SuperClass
+methodSuper()
TestSubClass2
SubClass2
+testMethodSuper()
+methodSub2()
+testMethodSub2()
TestSubClass1
SubClass1
+testMethodSuper() +methodSub1()
+testMethodSub1()

27. Why test
smells appear?

28. Wrong
step size

29. Many
increments in
the same test

30. Test code design evolves,
like the production code
design evolves!

31. Refactoring Test bar should
Production Code continue green
But some bad
smells can appear
in the test code!

33. ROUND 1

34. They have something in common...
Extract
Superclass
Pull Up
Method

35. There are some
duplicated tests
there!

36. Refactoring the tests!
Mirror
Hierarchy
to Tests
Add
Fixture
Pull Up
Test

37. ROUND 2

38. ScheduledExecution duplicate
some Action functionality.
Move Logic
to Delegate

40. The test is now covering one
possible composition of
ScheduledExecution, but it can be
composed by any Executor subclass!
Split Tests
From
Composition

42. Refactoring
Knockout

43. Refactorings that
change the classes
structure usually
create a test bad smell!

44. Future Vision
of Test Code
Refactoring

45. Automate
Test Refactorings
Creation of an Eclipse plugin to
automate test refactorings and
bad smell detection
independently from the test
framework.

46. Verify Test Behavior
Maintainance with Mutants
Create a tool that executes
tests on test target
mutants before and after
the refactoring to verify if
the test behavior was
changed.

47. “Unlike production code, which you
don't have a choice but to maintain,
tests are optional, you can always
stop running them and just throw
them away, and any investment
that you made (...) are just throw
out the window.“
Gerard Meszaros
Author of “xUnit Test Patterns“
Software Engineering Radio Podcast