Download to read offline
MockServer-driven testing
- 1.
- 2.
- 3.
- 4. 4 How They Automateon Mobile testableapple.com/big-tech
- 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
- 7.
- 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.
- 12.
- 13.
- 14. 14 ● Automated testingof the frontend does not depend on the backend state Pros
- 15. 15 ● Automated testingof 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 testingof 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 testingof 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 testingof 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.
- 20. 20 ● 👷♂️ Weneed to consider the costs of creating/implementing/maintaining a mock server Cons
- 21. 21 ● 👷♂️ Weneed to consider the costs of creating/implementing/maintaining a mock server ● 🐛 There's a possibility of bugs in the mock server Cons
- 22. 22 ● 👷♂️ Weneed 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.
- 24. 1. You're onlyinterested in testing the frontend 24 Use cases
- 25. 1. You're onlyinterested 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 onlyinterested 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 onlyinterested 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 onlyinterested 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 cameto MSDT
- 30. 30 Brief overview ofthe development process
- 31. 31 Brief overview ofthe development process
- 32. 32 Brief overview ofthe development process
- 33. 33 GitHub Actions Brief overviewof the development process
- 34. 34 GitHub Actions Brief overviewof the development process
- 35. 35 GitHub Actions XCTest Brief overviewof the development process
- 36. 36 GitHub Actions XCTest Brief overviewof the development process
- 37. 37 GitHub Actions Swift Package Manager Carthage XCTest Brief overviewof the development process
- 38. We need autotestscovering 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
- 39.
- 40. 1. Use twodevices/simulators at the same time 40 Proposed solutions
- 41. 1. Use twodevices/simulators at the same time 1. Create an autoresponder on the backend 41 Proposed solutions
- 42. 1. Use twodevices/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 twodevices/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
- 44.
- 45. 45 Native Standalone Same programminglanguage used in development, follows the same code style Mock Server
- 46. 46 Native Standalone Same programminglanguage used in development, follows the same code style Lives in the same project Mock Server
- 47. 47 Native Standalone Same programminglanguage used in development, follows the same code style Lives in the same project Easier to debug Mock Server
- 48. 48 Native Standalone Same programminglanguage 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 programminglanguage 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 programminglanguage 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 programminglanguage 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 programminglanguage 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 programminglanguage 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.
- 55.
- 56. 56 Stream Chat MockServer
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63. 63 Key points ofimplementation
- 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 tothe mock server 71 Pitfalls
- 72. Challenge Redirect SDK tothe mock server #if … #endif 72 Pitfalls
- 73.
- 74.
- 75. Challenge Redirect SDK tothe mock server #if … #endif Share the codebase with SwiftUI 75 Pitfalls
- 76. Challenge Redirect SDK tothe mock server #if … #endif Share the codebase with SwiftUI Swift Package Manager 76 Pitfalls
- 77.
- 78.
- 79.
- 80.
- 81. Challenge Redirect SDK tothe mock server #if … #endif Share the codebase with SwiftUI Swift Package Manager Sync mock server with the backend 81 Pitfalls
- 82. Challenge Redirect SDK tothe mock server #if … #endif Share the codebase with SwiftUI Swift Package Manager Sync mock server with the backend Stream Chat API 82 Pitfalls
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 93.
- 94.
- 95.
- 96.
- 97.
- 98.
- 99.
- 100.
- 101.
- 102.
- 103.
- 104.
- 105.
- 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
- 108.