Recommended
More Related Content
Similar to MockServer-driven testing
Similar to MockServer-driven testing (20)
Recently uploaded
Recently uploaded (20)
MockServer-driven testing
- 4. 4 How They Automate on Mobile testableapple.com/big-tech
- 5. 5
- 6. 6 1. Introduction to «MockServer-driven testing» methodology 1. Proof of Concept ❏ Creating Native Mock Server ❏ Creating Standalone Mock Server 1. Showcasing the methodology on the real project Contents
- 8. MockServer-Driven Testing (MSDT) is a methodology for developing automated UI tests, which is a custom branch of the Test Driven Development (TDD) methodology. 8 MockServer-Driven Testing
- 9. MockServer-Driven Testing (MSDT) is a methodology for developing automated UI tests, which is a custom branch of the Test Driven Development (TDD) methodology. The main idea is: ❏ To create a mock server that completely replaces the real backend ❏ To cover the features supported by a mock server with automated UI tests 9 MockServer-Driven Testing
- 10. MockServer-Driven Testing (MSDT) is a methodology for developing automated UI tests, which is a custom branch of the Test Driven Development (TDD) methodology. The main idea is: ❏ To create a mock server that completely replaces the real backend ❏ To cover the features supported by a mock server with automated UI tests TDD vs MSDT: ❏ TDD: developing unit tests to write application source code ❏ MSDT: developing mock server to write UI tests 10 MockServer-Driven Testing
- 11. 11 MSDT
- 12. 12 MSDT
- 13. 13 Pros
- 14. 14 ● Automated testing of the frontend does not depend on the backend state Pros
- 15. 15 ● Automated testing of the frontend does not depend on the backend state ● The tests’ speed is much higher because: ○ What requires a lot of hustle on the UI can be eliminated from the tests ○ What requires customizations on the backend can be driven from tests ○ What weighs a lot from the network perspective can work instantly Pros
- 16. 16 ● Automated testing of the frontend does not depend on the backend state ● The tests’ speed is much higher because: ○ What requires a lot of hustle on the UI can be eliminated from the tests ○ What requires customizations on the backend can be driven from tests ○ What weighs a lot from the network perspective can work instantly ● Mock server can "open up" the opportunity to write interesting test scenarios (mostly negative ones though) Pros
- 17. 17 ● Automated testing of the frontend does not depend on the backend state ● The tests’ speed is much higher because: ○ What requires a lot of hustle on the UI can be eliminated from the tests ○ What requires customizations on the backend can be driven from tests ○ What weighs a lot from the network perspective can work instantly ● Mock server can "open up" the opportunity to write interesting test scenarios (mostly negative ones though) ● Tests can check not only the UI reflection of responses from the server, but also the requests to the server itself Pros
- 18. 18 ● Automated testing of the frontend does not depend on the backend state ● The tests’ speed is much higher because: ○ What requires a lot of hustle on the UI can be eliminated from the tests ○ What requires customizations on the backend can be driven from tests ○ What weighs a lot from the network perspective can work instantly ● Mock server can "open up" the opportunity to write interesting test scenarios (mostly negative ones though) ● Tests can check not only the UI reflection of responses from the server, but also the requests to the server itself ● Developers can participate/assist in creating both the mock server and the tests Pros
- 19. 19 Cons
- 20. 20 ● 👷♂️ We need to consider the costs of creating/implementing/maintaining a mock server Cons
- 21. 21 ● 👷♂️ We need to consider the costs of creating/implementing/maintaining a mock server ● 🐛 There's a possibility of bugs in the mock server Cons
- 22. 22 ● 👷♂️ We need to consider the costs of creating/implementing/maintaining a mock server ● 🐛 There's a possibility of bugs in the mock server ● 🏃♂️ There's a chance the real backend will run off ahead Cons
- 23. 23 Use cases
- 24. 1. You're only interested in testing the frontend 24 Use cases
- 25. 1. You're only interested in testing the frontend 1. You want to manage the backend on the fly ○ e.g.: mock images, banner ads, etc. Use cases 25
- 26. 1. You're only interested in testing the frontend 1. You want to manage the backend on the fly ○ e.g.: mock images, banner ads, etc. 1. In tests you’d like to see/catch requests flying off the device ○ e.g.: analytics, custom events, etc. 26 Use cases
- 27. 1. You're only interested in testing the frontend 1. You want to manage the backend on the fly ○ e.g.: mock images, banner ads, etc. 1. In tests you’d like to see/catch requests flying off the device ○ e.g.: analytics, custom events, etc. 1. You need to emulate the interaction of several users ○ e.g.: chat, games, etc. 27 Use cases
- 28. 1. You're only interested in testing the frontend 1. You want to manage the backend on the fly ○ e.g.: mock images, banner ads, etc. 1. In tests you’d like to see/catch requests flying off the device ○ e.g.: analytics, custom events, etc. 1. You need to emulate the interaction of several users ○ e.g.: chat, games, etc. 1. ... 28 Use cases
- 29. 29 How we came to MSDT
- 30. 30 Brief overview of the development process
- 31. 31 Brief overview of the development process
- 32. 32 Brief overview of the development process
- 33. 33 GitHub Actions Brief overview of the development process
- 34. 34 GitHub Actions Brief overview of the development process
- 35. 35 GitHub Actions XCTest Brief overview of the development process
- 36. 36 GitHub Actions XCTest Brief overview of the development process
- 37. 37 GitHub Actions Swift Package Manager Carthage XCTest Brief overview of the development process
- 38. We need autotests covering the UI: a. Incoming/outgoing messages, reactions, attachments, etc. b. Online/offline c. In background/foreground d. On all supported iOS versions 38 Problem statement
- 40. 1. Use two devices/simulators at the same time 40 Proposed solutions
- 41. 1. Use two devices/simulators at the same time 1. Create an autoresponder on the backend 41 Proposed solutions
- 42. 1. Use two devices/simulators at the same time 1. Create an autoresponder on the backend 1. Develop a mock server to simulate the backend and the second participant in chat 42 Proposed solutions
- 43. 1. Use two devices/simulators at the same time 1. Create an autoresponder on the backend 1. Develop a mock server to simulate the backend and the second participant in chat 43 Proposed solutions
- 45. 45 Native Standalone Same programming language used in development, follows the same code style Mock Server
- 46. 46 Native Standalone Same programming language used in development, follows the same code style Lives in the same project Mock Server
- 47. 47 Native Standalone Same programming language used in development, follows the same code style Lives in the same project Easier to debug Mock Server
- 48. 48 Native Standalone Same programming language used in development, follows the same code style Lives in the same project Easier to debug Doesn’t require separate network requests (everything is controlled from tests) Mock Server
- 49. 49 Native Standalone Same programming language used in development, follows the same code style Lives in the same project Easier to debug Doesn’t require separate network requests (everything is controlled from tests) Parallelization out of the box Mock Server
- 50. 50 Native Standalone Same programming language used in development, follows the same code style Lives in the same project Easier to debug Doesn’t require separate network requests (everything is controlled from tests) Parallelization out of the box Works like a charm on CI Mock Server
- 51. 51 Native Standalone Same programming language used in development, follows the same code style Cross-Platform Lives in the same project Easier to debug Doesn’t require separate network requests (everything is controlled from tests) Parallelization out of the box Works like a charm on CI Mock Server
- 52. 52 Native Standalone Same programming language used in development, follows the same code style Cross-Platform Lives in the same project Easier to debug Doesn’t require separate network requests (everything is controlled from tests) Parallelization out of the box Works like a charm on CI Requires synchronization with the real backend Mock Server
- 53. 53 Native Standalone Same programming language used in development, follows the same code style Cross-Platform Lives in the same project Easier to debug Doesn’t require separate network requests (everything is controlled from tests) Parallelization out of the box Works like a charm on CI Requires synchronization with the real backend iOS: swifter, Android: http4k, okhttp, ktor rb: sinatra, js: express, py: flask, go: gin … Mock Server
- 54. 54 Mock Server
- 56. 56 Stream Chat Mock Server
- 57. 57
- 58. 58
- 59. 59
- 60. 60
- 61. 61
- 62. 62
- 63. 63 Key points of implementation
- 64. ● Mock server ○ crafted using swifter 64 Key points of implementation
- 65. ● Mock server ○ crafted using swifter ○ works with HTTP as well as with Websocket 65 Key points of implementation
- 66. ● Mock server ○ crafted using swifter ○ works with HTTP as well as with Websocket ○ runs on localhost 66 Key points of implementation
- 67. ● Mock server ○ crafted using swifter ○ works with HTTP as well as with Websocket ○ runs on localhost ● Tests ○ do not look at the real backend 67 Key points of implementation
- 68. ● Mock server ○ crafted using swifter ○ works with HTTP as well as with Websocket ○ runs on localhost ● Tests ○ do not look at the real backend ○ independent from each other because the mock server turns on before and turns off after every test 68 Key points of implementation
- 69. ● Mock server ○ crafted using swifter ○ works with HTTP as well as with Websocket ○ runs on localhost ● Tests ○ do not look at the real backend ○ independent from each other because the mock server turns on before and turns off after every test ● We ○ use Launch arguments and Environment variables to redirect the app to the correct server (the mock or production one) 69 Key points of implementation
- 70. ● Mock server ○ crafted using swifter ○ works with HTTP as well as with Websocket ○ runs on localhost ● Tests ○ do not look at the real backend ○ independent from each other because the mock server turns on before and turns off after every test ● We ○ use Launch arguments and Environment variables to redirect the app to the correct server (the mock or production one) ○ keep golden responses from the backend in the repo and use them as templates, to change/update on the fly during the tests 70 Key points of implementation
- 71. Challenge Redirect SDK to the mock server 71 Pitfalls
- 72. Challenge Redirect SDK to the mock server #if … #endif 72 Pitfalls
- 73. 73 source file
- 74. 74 source file
- 75. Challenge Redirect SDK to the mock server #if … #endif Share the codebase with SwiftUI 75 Pitfalls
- 76. Challenge Redirect SDK to the mock server #if … #endif Share the codebase with SwiftUI Swift Package Manager 76 Pitfalls
- 77. 77 source file
- 78. 78 source file
- 79. 79 source file
- 80. 80 source file
- 81. Challenge Redirect SDK to the mock server #if … #endif Share the codebase with SwiftUI Swift Package Manager Sync mock server with the backend 81 Pitfalls
- 82. Challenge Redirect SDK to the mock server #if … #endif Share the codebase with SwiftUI Swift Package Manager Sync mock server with the backend Stream Chat API 82 Pitfalls
- 83. 83 source file
- 84. 84 source file
- 85. 85 source file
- 86. 86 source file
- 87. 87 source file
- 88. 88 source file
- 89. 89 source file
- 90. 90 source file
- 91. 91 source file
- 92. 92 source file
- 93. 93 source file
- 94. 94 source file
- 95. 95 source file
- 103. 103 Android
- 104. 104 Android
- 105. swifter 105 Android
- 106. swifter ❏ http4k ❏ okhttp ❏ ktor 106 Android
- 107. ● testableapple.com/native-mock-server-inside-xctest ● github.com/testableapple/mockserver-driven-testing ● github.com/GetStream/stream-chat-swift ● github.com/GetStream/stream-chat-swiftui 107 Useful links