These are the code quality checks we do in our production system
Вставка
- Опубліковано 13 бер 2024
- My Products
📖 ProjectPlannerAI: projectplannerai.com
🤖 IconGeneratorAI: icongeneratorai.com
📝 ThumbnailCritique: thumbnailcritique.com
Useful Links
💬 Discord: / discord
🔔 Newsletter: newsletter.webdevcody.com/
📁 GitHub: github.com/webdevcody
📺 Twitch: / webdevcody
🤖 Website: webdevcody.com
🐦 Twitter: / webdevcody
![ПОЛНАЯ ИСТОРИЯ ЭКЗОРЦИЗМА [Топ Сикрет]](http://i.ytimg.com/vi/qBySr6Bt0B8/mqdefault.jpg)
I really like these production-related videos. We rarely get to see this on youtube.
Same here. I keep coming back to Cody's channel for this kind of content. Just great stuff.
grats on 200k ! nice insight into production checks always been curious
Great stuff, good to see what tests and checks a production codebase can have, thanks
Great video!
I would be glad to see some content on how you create/use mocks
This was really interesting. I just happened to start working on my teams CI/CD pipeline the other day. thanks!!!
These kind of video's are gems, more production-related content!
Great video as always! Would be nice if you also share how you guys do code reviews at work on another video.
What I'm looking now and can't find it, is a good explanation, how to add tests to existing react project, where to start, which test it should be?
If you'll think it`s a good Idea for future videos it will be great :D
yes agree. Need more video to show how to build the all integration test!
search for react testing library and jest
This is amazing! Could you cover in another video or reveal how you chunkified your unit tests into separate workers/jobs? I am trying to do something similar, but in Jenkins. Cheers!
I have sonarcube locally and the sonarlint I try to fix the max 😂 and I skip ton, and I like those type of videos man keep going 👏👏
This is very useful / interesting!
I'm in 3rd year of my uni, and i am a fullstack developer. I am creating my own SaaS (almost ready, waiting for payment gateway access). It's a React app, Nodejs backend and electronjs for a desktop application.
The think is, i have not written any tests or documentation. I do plan to write the documentation, but i have almost no clue about testing. It's a fairly complex application, mostly crud operations...
I have it all in my mind, and as i am solo developer, i left writing documentation. But midway i realized its a mistake. It'll take me probably a week to write the documentation, but i just don't have time and energy for it.
Don't worry about that! Just deploy your product and check if people want to pay you for that. If yes, then invest more time in testing and docs. Good luck! ✌️
That is a heck of a lot of production actions! We have 2 at my work - lint and test 😅
that's better than zero which is a majority of these buggy software projects
How do you spin up these different dependencies on the PR?
Additionally don't the build step of your image add an additional delay?
Good stuff! Wondering why you wouldn’t do some of these things at the commit stage, using Husky or something similar.
we do use husky for run some checks, such as eslint, stylelint, etc, anything more complex usually requires more time which we would rather pay compute for than to have devs waiting around letting their cpu fans turn into rocket engines
Hello @WebDevCody, Please explain how to set up those tests.
Your videos are really interesting , youtube is filled with big and small projects (some of them is really good ) but it is rare somebody talks about production grade codes and stuffs like that.
How do you properly write/ run tests in a container? I recently did something similar but when I ran the container in a GitHub workflow, it would run forever I had to set a timeout. The build would then show it failed :/ but tests would pass in the log :(
Thanks a lot for Sharing first-hand/real-world production knowledge. Do these GitHub actions need to run in a specific order or can they just run randomly?
They all run concurrently
That was areally helpful video! I was wondering how you were bale to start mock services like s3 on the client integration tests. Thanks for the amazing content!
There are a couple of third party packages, such as s3rver, which act as an s3 bucket endpoint where you can store and read files. Same with dynamo.
@@WebDevCody i am curious about your thoughts on a service like localstack and whether you would use something like that
Good job babe!
I would actually love to see how some UI unit and integration tests look like in this codebase, but some more complex example. Like how you actually approach tests. Do you mock everything, do you test with real code etc. I realized you mentioned mocks, but those were for 3rd party services you don't control. I'm curious about code that you own.
Would also love to see some of those custom actions and how they work.
Honestly, after the experiences I’ve had with mocking, I’d avoid it. By mocking, I mean if you are doing jest.mock or jest.spy. If something needs mocks to test, it sounds like you should just write an integration test to verify it all works together.
When I said mocks in this video I meant like a locally running dynamodb service, and a locally running s3 server, locally running es server. So they’re not the real thing we use in prod, but very close.
We also don’t test ui components. E2E cypress or playwright covers the ui well enough and isn’t brittle than testing implementation details. Testing is one of those things I’ve been doing for 10 years and I still don’t know the best approach. I think each feature needs to be looked to determine what level of testing would suffice to verify the feature. Approaching testing with dogma or strict rules just creates unnecessary tests.
@@WebDevCody "If something needs mocks to test, it sounds like you should just write an integration test to verify it all works together" -- that's my opinion as well. If something breaks because of a change in a dependency it has, I want to know it breaks. I think mocking creates a false sense of security in tests because you can actually break things, but tests will say everything is ok just because you created false implementations of everything around it.
Although I do agree with mocking things out of your control. Things you mentioned such as s3, dynamodb etc.
Regarding code coverage, do you use Cypress for that as well? I know it has some ways to output code coverage and since you said you aim for a really high code coverage I don't see how you could achieve that if you don't test your UI in some way.
@@rand0mtv660 oh we only care about coverage over business logic and entities. We don’t run coverage on cypress. I’m also in the mentality of coverage reports should just help you find where you have testing gaps and not as a gate keeping tool.
@@WebDevCody Ohhhh I see. Thanks for the details
Cody, you're creating so much value with your content that I have to say this next time: "Wake up, babe! A new video from Cody just dropped."
I dare you
Hey thanks for sharing, do you think it will be more efficient to run lint, typescript and units at first to simply fail fast ?
yes, we run linters on changed files using husky, unit tests would take too long to run everything
This reminds me of the setup I did at my previous job because I was sick of seeing slow tests. Did you guys set up any caching for the container images being used for these runs or is this the typical run for a cold start?
I'm assuming the cypress suite has a lot of internal dependencies that make that project difficult to break out since that seems to be the bottleneck at the moment.
I think we cache node modules in GitHub actions, but it doesn’t help too much
In, my company we cache the node_modules in s3 and the github action downloads the zipped node_modules from s3 . It resulted in so much time saving, because when we cache node_moduels in github actions only, the cache is not shared between different branches.
I have never seen a pipeline even one tenth this size. How long does the whole thing take to run?
The run time is in the video next to each task. The longest one was 13 minutes, the average is maybe 4-5 minutes. All of these tasks run concurrently, so the PR goes to passing in about 13 minutes.
@@WebDevCody 13 minutes isn't that bad. That's a lot of stuff, but your team seems to have a good handle on it all!
This is a pretty small pipeline compared to what you see in scaled enterprise apps. One of our services has a PR pipeline that takes over 2 hours to run.
That's gold
PDF generation is such a common requirement by big clients, but I've never written tests for them. Could you make a video about how you test that based on those popular libraries?
If I find time, but we just generate the pdfs using puppeteer from html templates generated from jsx and css. Then we take screenshots of each page of the pdf and save those as the expected images. Then on new code changes the tests regenerate the same pdf images against our expected, do a % difference by pixel values, then fail if they cross a threshold.
Are you able to integration test in RSC?
what does E2E Cypress Smoketests do? The number of tests are different?
It probably just makes sure the site loads at all with Cypress, hence smoketest.
I explained in the video. The smoketests run on the deploying UI hosted on the AWS environment and if they all pass, we do an automated color switch so that users get to the new (and verified) deployment.
How would set an integration type testing in github or gitlab setup?.
You can have the runner spin up Docker containers of other services and databases and connect to those. That's how I've done it and seen it done.
exactly, we spin up containers for the database, etc, then run your ui or api and run your tests
very insightful, but also scary, tbh.
what does you company work on?, finance?? This is crazy but if its generating money which it is, then its ok but wild
federal government
Could the order of some of these operations be optimised? For instance check the linting and TS errors first, then check unit tests lastly check the integration and smoke tests. That way your CI can fail faster and not spend as much money? Also things like linting and TS errors could be caught by pre-commit hooks or even you could seperate your CI/CD to do some minimal check on PR then more expensive testing when you wish to merge into main??
This is a very impressive pipeline and I'll have to get my team to look into pa11y !!
we run some of those checks in husky pre-commit, but you have to remember, if you run a set of tests before running the rest, you've essentially made your feedback loop longer. Sure, getting them to "fail fast" is nice, but often it's the integration tests that actually test the real system and fail when doing major code changes, so having to wait 6 minutes for the "pointless test" to finish before any integration tests kick off is actually more devs just waiting around for their integration tests to run.
additionally, if the project budget is high enough to support 10+ devs working full time, spending a couple hundred on ci/cd costs isn't a big issue IMO if it keeps a dev from needing to spend a few days fixing a bug we accidentally shipped.
@@WebDevCody that's a fair point, I couldnt see unit tests taking more than a couple of minutes tho but js is slow aha
@@dandogamer I think our code needs some refactoring because the unit tests take a while. Jest is slow, add on top typescript which needs to be transpiled, then we also have a god module we import basically everywhere which kills performance. Bad design choices made 5 years ago but we learn the consequences now as we added more and more tests
How long does that take to run? Impressive
13 min is the longest worker, average check is maybe 5-10 minutes
Have you noticed any slowdown in development time due to the need to write a lot of tests alongside the actual features (and the need to rewrite tests once requirements change)?
Tests slow down development up front but speed you up as the project grows because they help prevent bugs
@@WebDevCody My question is around the same concept.. although I think tests are important .. can you give an example using a small feature about the time estimates you give as a developer taking into account unit tests, e2e.. I know it all depends on the developer's skill level but still what can be a good estimate for a specific feature keeping account of testing..
Do you follow Agile development?
how long is your sprint?
what is the avg ticket count completed per sprint?
That is a proper checklist ahah. Maybe couple of more actions to check that the world still exists and you should be confident you can deploy safely.
Should add some extra tests to make sure the developers drink water and go to bath room
Wtf this is several hours of actions. How many are yall able to run in parallel
A lot of
None of my code would every get pushed to prod if Im not allowed to use "any"😀😀
First!!
Seems bit an overkill
how many tests does your project write?
Back-end has almost 80-90% unit/integration test coverage, which is fine I guess, although I’m not a proponent of full coverage.
Front-end primarily relies on e2e tests. 90% time writing unit tests for fe components is waste of time, imo.
@@katanaut that sounds reasonable. So do you run pa11y or axe for accessibility? What about linters? We don’t unit test any of our react components, just the presentation logic used by the frontend.
Sorry but i think your ci/cd very slow and run a lot of things
what does your pipeline test?
@@WebDevCody
I am just maintain backend so i will run less small things and a language have a better tool builtin, so i run static code checks and testing just that
@@WebDevCody but consider it just backend
@@WebDevCody feature testing and unit tests and most of functionality is real time
man... i really envy this level of company... i only worked in 2 companies so far and both don't have any tests or ci/cd pipeline 😅 things just keep breaking every day and we just keep "fixing" them, so we dont have time to stop and write tests, even more so in my new job where we are only 3 devs in a 20 years old company that have a bunch of huge clients 🥲🥲🥲🥲🥲🥲🥲🥲🥲🥲
this is the exact reason why we write tests. It’s a lot of extra work but it saves you time and money in the long run, at least that’s the idea. I’m sorry to hear about your suffering