Nitrogen on your test Pyramid (2) test by design

Test by design slides for the presentation i did in Virtual Android Makers 2020.

Transcript

1. Nitrogen On your test pyramid 2
2. Enrico Bruno Del Zotto @enricobdelzotto
3. how to better organise your tests
5. Quick recap
6. Unit Integration End to End
7. Android X Test Library
8. 1. TEST Transfer of Environmentally Sound Technology 2. TEST Treadmill Exercise Stress Test 3. TEST The Simputer Trust (Indian Institute of Science and Encore Software) 4. TEST Thermal Energy Storage Technology 5. TEST Trade in Environmental Services and Technologies (USAID) 6. TEST Telemedicine and Education Support Team (UK) 7. TEST Textile Employment Support Team TEST
9. Android X Test Library
10. “Code refactoring is the process of restructuring existing computer code—changing the factory—without changing its external behavior.” - Wikipedia REFACTOR
12. Self-descriptive Simple SOLID Anatomy for a good test
13. Yes, SOLID
14. Keep your test targeted Keep it simple
16. Do not test multiple things! One thing at a time
18. Do not repeat yourself Abstraction of similar objects Minimal dependencies
20. Go directly to the “scenario” Keep your test agnostic! agnostic:“someone who does not know, or believes that it is impossible to know”
21. Need of level of abstraction! Don’t care of : Idling resources / async events Data layer (Network,db etc.)
22. It means : Inject your data Sync if needed Test condition, and assert
23. Inject your data Hooking your application modules. (use fakes like mock web server)
25. Sync Background operations Prefer to mock out Idling resources
27. Test & assert
30. Uncle Bob says: Keep your test code to the same level of quality to the production one. Test code isn’t throw-away code.
34. Page object pattern (Martin Fowler) Kotlin DSL
37. • Very easy to read • Very easy to extend • Good level of abstraction (no need to change test if flow isn’t changing)
38. • It’s not clear the starting state of the test • Assertion are hidden
39. How better could we `assert`?
40. Organise your own ‘ui’ (design) test pattern based on your own production code architecture
41. Hannes Dorfmann, Kostiantyn Tarasenko — Testing by design
42. State based architecture Single source of truth States rendered on the ‘screen’
43. Inject your first source of truth and launch the scenario
45. Creating the test Robot with the assertions
46. Binding the view
50. Failing UI tests Code refactor Passing UI tests Failing unit tests Passing unit tests Refactor
54. Reliable Accurate Fast Good test suite
55. End2End tests will cover user journey in the app Covering high level reqs ‘what user will see’ means refactor process will be faster. Choose your ‘ui’ test design pattern Your design architecture can help you If you start a project from scratch keep in mind the ‘test per design’ approach. TL;DR
56. Thanks @enricobdelzotto