This is why testing is hard
Вставка
- Опубліковано 23 гру 2023
- 📘 T3 Stack Tutorial: 1017897100294.gumroad.com/l/j...
🤖 SaaS I'm Building: www.icongeneratorai.com/
▶️ Generate Chapters: ytchaptersgenerator.com/
💬 Discord: / discord
🔔 Newsletter: newsletter.webdevcody.com/
📁 GitHub: github.com/webdevcody
📺 Twitch: / webdevcody
🤖 Website: webdevcody.com
🐦 Twitter: / webdevcody
Great video as always. It's nice to see educational videos that more about real world stuff and not about twitter fancy trends and rants.
Please, do some more about integration testing with more meat, examples of code and CI/CD setups. It would be pure gold!
Good aproach in writing integration testing is to write them as some use case scenario. Like first step is user opens some page to see some data, so you test some get endpoint for that. Next user tries to add some data, so that means using some POST endpoint, then user want to see result, so again endpoint for geting data.
I love the way you make videos! I've seen some other vids on testing but they're mostly rant opinion videos, but you actually teach in yours, so thank you!
Thank you for the clarity. Great video and awesome diagrams. Just started creating unit tests and integration tests and my first questions were around the scope and how much to test. The black box approach and not getting into the implementation details of my system helped a bunch.
Im probably going to drop this in a few of the discussion channels we have at work. It pretty much hits the nail on the head. The one thing that I'd add is that the real decision maker between smoke and e2e is that an e2e test needs to be able to run as part of a build step: it shouldn't include anything that can't be provided by docker-compose up. There's a lot of tooling out there to make that easy. Smoke tests should either be your manual cases or part of a blue-green deployment pipeline. If you've gotten that far then expect everything to be good because all other tests have passed, but it's best to have business critical stuff validated so that any manual testers don't start burning the clock until you know they're not going to find something that gets you paged in the middle of the night.
I used to think everything had to be deployed before QA touched it. My last gig switched over to having integration tests with wiremock or something similar and the end result was deployments took minutes and we didn't get paged for an incident for two years on any service using the new pattern.
Nice dude. Merry Christmas.
I've gotten hooked on your videos Cody! You explain things well, and as people have mentioned, you dive in to very practical real world examples. I love your whiteboarding sessions and explanations of system architecture and how and when to implement different strategies. Keep up the good work 🍻
Can you make a video about how to set up the services to use while testing, you spoke about this in the video. It would be very interesting. Also how to use it then in the application to switch the the endpoint based on if it’s local/test/prod env.
And thanks for the video!
ty mate
19:50 you can test your UI without having the entire system up and running. The server can be mocked and the UI tested effectively. Even if you do UI tests with a fully operational system, it doesn’t guarantee the deployed system will always work. Theres the potential for parts of the system to go down due to network or configuration issues. That’s where health checks come to the rescue to verify dependencies are accessible and connected correctly.
I have a few years of experience as a QA automation, I must say that the trophy approach makes quite a lot of sense IF THERE IS A QA IN THE DEVELOPMENT TEAM because static testing involves testing the code without running it. For example a CR. Anyways enough of that, great video! I would be happy to see some playwright content
Good job bub!
Awesome content
Great video
So from what I understood : unit testing = pure function, integration testing = function with dependencies ( whether its from backend, or other services, other functions), e2e = simulate user actions.
Love your videos! Would you consider making a video on how you realistically extend functionality without breaking things (if you follow SOLID) and when breaking things is inevitable. A video with a more realistic, production example.
Break free from control.
The problem in unit test it that they are bound to single functions or classes, but those clasees not always are reflecting actual features. But the main reason for changing the code is actually change in requirements and you want to have easy way of changing code to those requirements, not to single functions or classes.
Yeah absolutely. Maintaining all those units makes it way harder to do refactors. It's much better imo to focus on integration tests and test your API end points do what they are supposed to when the app is in a certain state. That way your tests are almost a statement of intent for how the app should work, and you can refactor to your heart's content and know that things still work when all your tests pass.
I think you have missed a crucial example for unit tests. If you have a complex system and a single endpoint has over 500 cases, then 500 integration tests is not a good idea. you rather want like 2 integration tests and 498 unit tests, test all you logic without any infrastructure, because the integration to the infrastructure was tested in and integration test. If you don't like the term unit test, then call them component tests or whatever.
Awesome video, man.
I love your content.
It's been a long time since I saw any Vuejs videos.
What happened?
I’m Just double downing on react / next at this point
How would you solve problem to have hover effect on each floor on buliding image? Any advice
Maybe make an overlapping div for each floor with a hover effect on the div
I usually struggle with grasping the point of unit tests. I feel like when you have these "atomic" utility functions and you have them refined to the point that they just work the way you expect them to, what's the point of unit tests then? Aren't my functions done like more or less forever? Or is the point of UT to help you get to this point?
Itd hard to me to understand the line between unit and inregration tests, integratuon its when you test a parent of couple of functions or compontnts?
Integration imo is when you have multiple components integrated together, so for example and api integrated with a local Postgres database. Or a Ui integrated with an api. It’s a spectrum, you can always integrate with more things up until you reach the point where you are testing on a 100% live system.
I don't understand the point of QA when the industry expects testing to be done by the developers themselves, whether that be manually testing in local environments during dev or writing unit/integration/e2e tests for new feature work.
Qa is just another line of defense to find bugs, but I’d say qa engineers should understand how to write e2e tests and help test the system for various edge cases. You can still have qa do manual check offs on stuff because they often should have a better understanding of how the entire system should work together, but the more manual testing you add the longer and longer it takes to get a single change deployed to prod. I’ve seen teams take weeks to deploy a text change because of process
Can you please show a real life example? maybe with more details and some implementation. Especially API
Sure I can work on something
Thank you Cody :) @@WebDevCody
web dev cody fbi confirmed
👀 🤫
If you find it hard and using to much time for unit tests you are not writing single responsibility and clean code. Devolepers usually abuse logs and debuger instead of writting single test that will check the thing and also make sure that future developers will not reintroduce the bug or brake functionality. This is the same case as using vim motions until you learn it proberly you think it is useless and outdated.
4:17 shouldn’t AI outputs be deterministic?? Unless there is some forced randomisation, a trained model should always give the same output for the same input.
Unit Tests for mobile/web apps are waste of time. It's necessary in security and safety related environments, but not for regular apps which arw 99% or all apps.
But even in regular apps, when you refactor a module, it can be useful to write a few low-effort mock-heavy sort-of-unit tests for verifying the module's logic.
It's lazy, it's incorrect and it's not part of accepted best practices, but it makes refactoring less stressful and doesn't burden you with the stress of writing proper unit tests.
Simply put: capture "snapshots" of the state at several key points along the old code, use these snapshots as mocks, write tests that make sure state undergoes the same transformations as before every time you run the test.
That way you'll catch subtle bugs in the module's logic soon after making a change that causes them. Which can happen during refactoring. And if it does happen, it's infuriating.