The document discusses simplifying test automation through the use of design patterns. It begins by defining code smells that make tests complex, such as duplication, conditional logic, obscure tests, and fragile tests. It then explains several design patterns that can address these smells, including template method for removing duplication, strategy for replacing conditional logic, factory/builder for constructing complex objects, composite for grouping objects, and decorator for adding responsibilities dynamically. The document advocates for clean, well-structured test code through applying these patterns.

1. Simplifying test automation
with design patterns
Ivan Pashko

2. Speaker info
Ivan Pashko, Ukraine
Scrum Master in Betsson, Ciklum
• 8+ years in the IT
• Software Automation Developer
/in/ivan-pashko-33208042/
/groups/1180099188730673

3. Code smell

4. Clean code
Code is clean if it can be understood
easily – by everyone on the team, going
over a long time

6. Why Design Patterns?
General repeatable solution to a commonly occurring
problem in software design.

7. Test smells
• Test Code Duplication
• Conditional Test Logic
• Obscure Test
• Fragile Test

8. Test smells
• copy/paste
• if-else
• inheritance /overrides
• data sensivity (hardcode, magic values)

9. Test smell. Copy/Paste
• Duplication increases
the cost of maintenance

10. Template Method
• Defines the skeleton of
an algorithm in an
operation,
• Deferring some steps to
subclasses

11. Template Method
public class MonitoringNotificationBaseTest<T> where T : BaseNotificationData
/// <summary>
/// Method perform next steps:
/// 1. Create New Notification
/// 2. Update Notification
/// 3. Check Enable/Disable Button
/// 4. Remove Notification
/// </summary>
/// <param name="defaultNotification">Used in 1 step</param>
/// <param name="updatedNotification">Used in 2 step</param>
public void CRUDNotificationTest(T defaultNotification, T updatedNotification)
{
CreateNewNotification(defaultNotification);
UpdateNotification(updatedNotification);
CheckEnableDisableButton();
RemoveNotification();
}

12. Test smell. Conditional Test Logic
Makes tests more complicated than
they really should be.

13. if (element.Exist())
{
AssertElementContext(element);
}
else
{
AssertErrorMessageAppeared();
}
if (element != null)
{
element.Click();
}
• What condition is
passed?
• What if condition failed,
but test is green?
• What is test fail?
Test smell. Conditional Test Logic

14. Strategy Pattern
Enables an algorithm's behavior to be selected at
runtime

15. Factory Pattern
• Hides the logic of
initializing an object
inside the factory.
• Refers to the object
using a common
interface instead of
the concrete class.

16. Test smell. Inheritance /overrides
Blind inheritance and overrides leads to the
creation of «Monster» objects

17. Composite Pattern
• The composite pattern
describes a group of
objects that is treated the
same way as a single
instance of the same type
of object.

18. Decorator Pattern
• Attach additional
responsibilities to an
object dynamically.

19. • Revealing Naming
• Replace Magic Numbers
with constants
• Use builder for defaults
& complex object
creation
//Revealing naming
List<string> list1
List<string> userNames
//Magic numbers as constants
FindByAge(33);
const int OLD_USER_AGE = 33;
FindByAge(OLD_USER_AGE);
Test smell. Data sensitivity

20. Builder Pattern
Separates the construction of a complex object from
its representation

21. Builder Pattern
public class User
{
//Required parameters:
public string Email { get; set; }
public string Login { get; set; }
//Additional parameters:
public string Name { get; set; }
public int Age { get; set; }
public string Address { get; set; }
}
• Typical test user object:
• Required fields
• Additional fields

22. Builder Pattern
//Telescoping constructor
new User(email, login);
new User(email, login, "test name", 18, "test address");
//JavaBeans
new User("test@gmail.com", "test_123")
{
Name = "Name",
Age = 18,
Address = "test address"
};
• Copy / paste
• Constructor overrides
• Helpers methods
As a result:
• A lot of code
• Duplicates
• Unclear defaults

23. Builder Pattern
new UserBuilder("test@gmail.com", "user_123")
.Name("Name")
.Age(18)
.Address("test address")
.Build();
public UserBuilder(string email, string login)
{
_user = new User(email, login)
{
//Default values:
Name = "Default Name",
Age = 18,
Address = "Default address"
};
}
• Easy to read
• Simple to extend
• Safe defaults

24. Your test smells if
• contains if’s
• has a ‘twin brother’
• depends on the data
• doesn’t feet in one screen
• bypass your framework

25. Good test
is like a
good joke
- it needs no explanation

26. Thank you
Useful links:
http://blog.bbv.ch/wp-content/uploads/2013/06/Clean-Code-V2.1.pdf
http://xunitpatterns.com
https://sourcemaking.com
Questions?
You can also ask questions for me in the lounge zone