This document introduces agile automated unit testing. It discusses problems that can occur without testing, such as interruptions, concentration loss, and estimation failures for users, developers, and managers. Manual testing is time-consuming and inaccurate. Agile practices like breaking work into smaller testable units and test-driving development help address these issues by allowing for more accurate estimations, focus, early problem detection, and feedback. Automated unit testing with practices like test-first development and BDD make software development more enjoyable, productive and ensure requirements are met.

1. An introduction to
agile automated unit
testing

2. Mohsen Bazmi
 Help the management to plan and have control over the process
 Internalize the agile software development for my dvelopers
 Help my developers to grow and be useful for stackeholders
 Hep the team and smoothen the development path
 Architect, design, and develop microservices
 Design and develop infrustructural frameworks
 Solve other technical issues
Technical Leader Consultantant

3. What is the unit Testing?
Why should I bother?
What about agile?
How are they related togather?
A brief introduction to :

4. Problems of
 Users
 Developers
 Managers

5. Release

6. Get users to test the software

7. Users
 Ripple effect of unstable software on customers’ organizations
 Users as testers
 Distrustful users
 Angry users

8. Developers
 Exhausted bored developers.
 I’m working as fast as I can.
 I need to think about too many things at the same time while developing.
 The project moves too hard.
 I cannot focus.

9. Managers
 All estimations are filed
 Force release causes qualirty reduction.
 Angry stackeholders because of disorganized developers.
 Developers need to be pushed

10. Vortex
Developer
Manager
User

11. Vortex
Developer
Manager
User

12. So what is the
solution?

13. What is manual testing?
 Manual test after development, before release
 Bug report forms

14. What’s with manual testing?
 Interruptions
 Concentration loss
 Estimation Failure

15. Force release
The problem remains
 Interruptions
 Concentration loss
 Estimation Failure
 Business Failure
 And mentioned troubles

16. What’s with manual testing?
 It’s not specific
 Time consuming
 Unstable
 Inaccurate
 The feedback loop is too long
 Boring
 Brittle
 Disorganized
 Is not agile
 And much more

17. How to estimate the time?
 Who can estimate the time without quality loss?

18. How to estimate the time?
 What about a sum application?
 Who can estimate accurately?

19. Requirements
Demo
P.O:Calculator1+2 should equal 3

20. Who cannot estimate it?

21. Demo
Implementation
What do you expect?

22. Agile
 Break the job into samller ones.
• Tests
• Requirements
• Documents
• Architecture
• Estimation
• Deployment
• And more

23. Invite yourself to the party of your success
Break it

24. Invite yourself to the party of your success
Break it

25. Invite yourself to the party of your success
Break it

26. Invite yourself to the party of your success
Break it

27. Invite yourself to the party of your success
Break it

28. Invite yourself to the party of your success
Break it

29. Agile
 Quality reduction is not permitted even for buying time.

30. Agile
 There is no later. Do it right now.

31. Agile
 Only satisfy the requirements with a high quality. Not more(YAGNI)

32. Agile
 There is (probably) no more important job than current one

33. Agile
 Measure based on statistics and probability
 Learn
 Improve

34. Agile
 Improve the company culture.
 Make the feel of synergy responsibility and happiness.

35. Automated unit testing
Demo
Unit test
the sum

36. Benefits
 It’s automatic
 It’s fast
 It’s accurate
 The feedback cycle is short
 I find the problem early
But
• Focusing on requirements is still hard.
• Still no confidence
• Still no focus
• Still boring
• Sometimes I’m too busy that I forget to write the test

37. Fixing the bug in production
8

38. Test First
Demo
Let’s write the test first

39. Test driving small units of work
 Easy to focus on. No more confusions.
 Easy develop.

40. Small but complete and estimatable
units of work
 Easy to estimate the time for.
 Measure the estmation loss of your small tasks for you.
Task Estimation Actual
Sum 2 min 3 min
Subtract 4 min 2 min
Total 6 min 5 min

41. Requirements
 Should be attached to the test

42. Descriptive test names
Demo
Let us attach the requirements

43. Test driving small units of work
 Easy to document
Who likes to read documenrs?

44. BDD
Demo
Let’s add the documentation

45. Test driving small units of work
 Easy to report.
 Who likes reporting?

46. Reportable
Demo
Let’s see how the viewers see the reports
The green lovely lights

47. Test driving small units of work
 Easy for stackeholders to plan based on small But more accurate estimations
(using probability and statistics) %

48. Test driving small units of work
 Makes you feel confident, progress , and
achievement.
 You will love those small green lights!

49. Test driving small units of work
 Makes you feel happiness and synergy

50. Test driving boxes of work
 Doesn’t bore you any more

51. Safty net
 Changes that do not follow the requirements set alarm.
 Safer against refactoring.(safty net)
 You are following your Product Owner

52. Small tested units of production code
 No need for pushing, they pull the job, and report the progress reactively.

53. Small tested units of production code
 Small high quality pieces of software
 Happy stakeholders
 More stable and less buggy
 Reduces the overall cost

54. Fixing the bugs in production

55. Fixing the bugs in production

56. Vortex
Developer
Manager
User

57. The End.
Thanks for listening
https://www.linkedin.com/in/
Mohsen-Bazmi-Software/