MageConf 2020 talk on TDD and how to test Magento 2

1. Page | 1
Where have we been and what
do we do?
The Future of
Testing Magento 2

2. Page | 2
About Me
James Cowie
● CTO @ Shero Commerce
● Magento Master
● BDD / TDD advocate
● @jcowie
● @sherocommerce

3. Page | 3Page | 3
➔ “The process of learning effective TDD is the process of
learning how to build more modular applications.”
The Goal

4. Page | 4Page | 4
➔ “The process of learning effective TDD is the process of
learning how to build more modular applications.”
The Goal

5. Page | 5
The Reasons to not test
➔ We don't have the budget!
➔ We don’t have the time!
➔ Testing slows us down!
➔ We don’t have the training!
➔ It gets in the way!
➔ The client won’t pay for it!
➔ The tests become out of date
➔ They run slow and hold us back!
➔ Ship first test later

6. Page | 6
Group the historical reasons
Time Knowledge Understanding
Testing slows us down! We don’t have the training! Ship first test later
We don’t have the time! The tests become out of date They run slow and hold us back!
We don't have the budget! Ship first test later
The client won’t pay for it!

7. Page | 7Page | 7
Time

8. Page | 8
Time to add features over time
without tests
● Faster to start with
● Slows down due to large code
● More time spent manual testing
● Higher chance of defects

9. Page | 9
Time to add features over time with
tests
● Does add time initially
● Get faster for feature development
● Less chance of defects
● Better use of time on exploratory
testing
● More maintainable

10. Page | 10
Time Conclusion
Testing slows us down
Over time testing speeds you up.
We don’t have time
Having tests will shorten delivery time making more
time.
The client won’t pay for it
Clients don’t need to know how you cook the steak.
Instead, they will pay for excellence and high quality.

11. Page | 11Page | 11
Knowledge

12. Page | 12
Knowledge. The hard truth
➔ Testing is _hard_
➔ Architecture can hinder
➔ Complete mind shift
➔ Is a whole team sport

13. Page | 13
Knowledge. Current design

14. Page | 14
Knowledge. Current design

15. Page | 15
Has this been solved before?
➔ Ports and Adaptors
➔ Hexagonal Architecture
➔ DDD
Alistair, Cockburn (2005-04-01). "Hexagonal architecture". alistair.cockburn.us.

16. Page | 16
Knowledge. Future design

17. Page | 17
Knowledge. Future design
Adaptor
Port

18. Page | 18
Ports
➔ Slim Magento 2 module
➔ Contains no business logic
➔ Traditional Magento 2 module

19. Page | 19
Adaptors
➔ The custom implementation,
➔ Business logic
➔ Dependency inverted,
➔ Injectable

20. Page | 20
The Bridge
➔ Can be an API
➔ Dependency Injection into slim Magento 2 client
➔ Responsible for linking the 2 systems

21. Page | 21Page | 21
Types of testing

22. Page | 22
Types of testing
➔ Unit Testing
➔ Integration Testing
➔ Acceptance Testing

23. Page | 23
Unit Testing
➔ Internal testing (Inwards)

24. Page | 24
Integration Testing
➔ Outside facing testing (outwards)

25. Page | 25
Acceptance Testing
➔ Does it work?

26. Page | 26
What tools are available?

27. Page | 27
Pick the right tool for your team
➔ Not all tools are equal,
➔ Varying levels of effort and knowledge,
➔ Used in different scenarios.

28. Page | 28
Behaviour Driven Development (BDD)

29. Page | 29
More traditional TDD

30. Page | 30
What hinders testing?
➔ Inheritance
➔ Tight Coupling
➔ Testing after concrete code is wrote

31. Page | 31
Favour Composition
• Blueprints to the concrete
implementation
• Describe functionality.

32. Page | 32Page | 32
TDD workflow

33. Page | 33
The TDD dance

34. Page | 34
The TDD dance
Write a failing test

35. Page | 35
The TDD dance
Write just enough
code to make the
test pass

36. Page | 36
The TDD dance
Refactor the code
to be complete

37. Page | 37
Think design / architecture
➔ Your only thinking about small units,
➔ Refactoring is safe,
➔ Your designing with interfaces,
➔ Stops gold plating.

38. Page | 38Page | 38
• This is a simple module but should highlight how simple
setup can be.
Lets see this in practice

39. Page | 39
The module / Demo
PayMate LTD provides the ability to part pay for goods and
split it over a number of months. They handle the payment
side of the process but they need the product details page to
show the split. The business rules are:
• Products under $50 can be split into 2 monthly payments
• Products under $200 can be split into 4 monthly payments
• Products over $500 can NOT be split

40. Page | 40
Code Structure

41. Page | 41
Bootstrapping

42. Page | 42
Failing Testing
Fail

43. Page | 43
Failing Testing
Fail

44. Page | 44
Failing Testing
Fail

45. Page | 45
Make it green (small increment)
Pass

46. Page | 46
Make it green (small increment)
Pass

47. Page | 47
Failing Testing
Fail

48. Page | 48
Failing Testing
Fail

49. Page | 49
Write just enough code to make it
pass
Pass

50. Page | 50
Failing Testing
Fail

51. Page | 51
Failing Testing
Fail

52. Page | 52
Write just enough code to make it
pass
Pass

53. Page | 53
Introduce a Mock

54. Page | 54
Using the mock to get price

55. Page | 55
v
Disclaimer
The way I use the registry is NOT complete
and also bad practice.

56. Page | 56
Make it do something

57. Page | 57
Integration testing

58. Page | 58
Integration testing

59. Page | 59
Integration testing

60. Page | 60
Integration testing

61. Page | 61
Integration testing
➔ Mink offers helpers
➔ Use a Magento driver

62. Page | 62
Refactoring Step
➔ Now that the tests pass Refactor!
➔ Remove the hard values for dynamic
➔ Keep running the tests

63. Page | 63
Integration testing
➔ Behat runs via Selenium
➔ The feature context is the powerhouse
➔ Its slower than Unit tests
➔ Can be optimized via Behat plugins

64. Page | 64
v
Overview of our testing
PHPUnit
Behat
Core Domain

65. Page | 65
Where to go from here?
➔ To team code katas
➔ Keep practicing
➔ Watch Vinai’s kata series
➔ Watch out for Fabian Schmengler book

66. Page | 66
Thank You