АНДРІЙ ШУМАДА «To Cover Uncoverable» Online WDDay 2022 js
•Download as PPTX, PDF•
0 likes•10 views
Online WDDay 2022 js АНДРІЙ ШУМАДА «To Cover Uncoverable» Сайт: https://wdday.org/ Facebook: https://www.facebook.com/wdday.org Linkedin: https://www.linkedin.com/company/wdday
Report
Share
АНДРІЙ ШУМАДА «To Cover Uncoverable» Online WDDay 2022 js
- 2. It’s about tests! ...and infrastructure around them!
- 3. Why do we need tests*? * by tests I mean autotests. I’m a developer(R&D Team Lead). I hate manual testing.
- 4. We want to have less bugs in production!
- 5. How our production looks like? Frontend Backend DataBase Web server HTTP Requests
- 6. How our backend tests should look like Tests Integration tests MongoDB Node.js HTTP Requests
- 7. Requirements for our tests 01 04 02 03 Easy to write Easy to setup locally Easy to setup in CI/CD As close to production environment
- 10. Patron, dog mascot of the State Emergency Service of Ukraine *Patron translates as “bullet”
- 11. Mac OS Windo ws Linux Intel 1 2 ∞ Arm 3 4 ∞ What are the options to run 3rd parties? (MongoDB) Pros: - easy to run in all envs 01 02 Mock it Run real db on your computer Cons: - Will not represent production - Chance to implement mocks wrongly Pros: - Familiar way to start DB - Real DB Cons: - Different setup for local envs and for CI
- 12. Where we can run 3rd parties? (MongoDB) 04 03 Use dedicated cloud infra for tests Run everything in docker ecosystem Pros: - As close to production as possible Cons: - Hard to isolate test runs - Might require VPN access to internal resources - Can cost money Pros: - easy to run in all envs - Close to production Cons: - Initial setup might take some time - Debug in containers is harder
- 13. Running tests in Docker infra is hard? 01 04 02 05 03 Build image for an app Spin all the services Run tests in container Change the code or the tests Repeat 1 and 3 and 4?
- 14. What If I tell you that we can solve all our problems with one command? docker compose run --rm nodejs-app-test
- 15. docker compose run --rm nodejs-app-test docker-compose.yaml
- 17. Dockerfile
- 18. Easy to setup in CI (gitlab)
- 21. …as well as on github.com
- 22. How our production looks like? (2) Frontend Backend Queue Node.js app HTTP Requests
- 23. What’s wrong with Kafka tests? ● Recreating topic is time consuming ● There is no key-value access ● Failed test runs can produce more messages then read
- 24. Sample Kafka producer app https://github.com/eagleeye/to-cover-uncoverable/tree/master/02-kafka https://gitlab.com/andrii.shumada/to-cover-uncoverable/-/tree/master/02-kafka
- 25. Simple test with kafka
- 27. Start zookeeper Start Kafka Build Node.js Docker image Run tests Order of subtasks to run tests with Kafka
- 32. How our production looks like? (3) Frontend Backend Node.js app HTTP Requests
- 33. Localstack - mocks of AWS services docker-compose.yml https://localstack.cloud/ * * better to fix version - Lambda - Kinesis - Redshift - DynamoDB - ElastiCache …and 45 more services
- 34. Node.js app DataStore Cloud functions Big Query Not all the 3rd parties we can run locally…
- 35. For DataStore Managing shared cloud resources could be hard, specially when you have multiple developers trying to reach your resources
- 36. Cloud function Option 2 Spin up cloud function emulator Write unit test for controller Option 1
- 38. What if our production production is even more complex? (4)
- 39. We tested all the gears, but will it work a gearbox..
- 40. No way that you can write that complex test…* You need more than 1 team to develop, maintain and test that *I know you can,,,
- 41. Where we can run 3rd parties? (Google services) 04 03 Use dedicated cloud infra for tests Run everything in docker ecosystem Pros: - As close to production as possible Cons: - Hard to setup isolation for separate tests - Might require VPN access to internal resources Pros: - easy to run in all envs - Close to production Cons: - Initial setup might take some time - Debug in containers is harder
- 42. Continuous QA in Qa environment to the rescue! Service that constantly sends data in QA (emulates clients) HTTP Requests Grafana (any monitoring) Zoo of services and 3rd parties
- 44. How I know that my product (apps and infrastructure) works properly in production? 1) I don’t receive calls from support and my boss 2) Metrics and alerts
- 45. Metrics and alerts on: - Status codes - Number of error logs - Business metrics - Container restarts - Resources usage How can I know, that my product works in QA?
- 46. Example of continuous test Client automation HTTP Requests - 10 valid POST /pets requests with unique pets - 5 invalid requests - 5 valid GET /pet/:id requests - 15 of 200 status codes - 5 of 400 status codes - Incoming records per second in topic should be 10 - Increased number of items in your database by 10 - Cloud function was executed 10 times - Cloud function executions finished without errors - No logs with severity > error - No restarts in all containers - CPU, memory, disk metrics should be < 80% - ….. Sends similar requests Every second
- 47. Conclusion - Use Docker compose infrastructure to organize your local development infrastructure and as infrastructure for tests locally and on CI/CD - Use continuous testing in your QA environment by making automated requests to your infra and monitoring should catch problems if they occur
- 48. Thanks! Do you have any questions? Leave them in Youtube comment or Discord: Voice Chat: Voice WDDay eagleeyes91@gmail.com https://eagleeye.github.io https://gitlab.com/andrii.shumada/to-cover-uncoverable https://github.com/eagleeye/to-cover-uncoverable https://u24.gov.ua/ Remember to support Ukraine!