Same here. I keep coming back to Cody's channel for this kind of content. Just great stuff.

yes agree. Need more video to show how to build the all integration test!

search for react testing library and jest

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's better than zero which is a majority of these buggy software projects

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.

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.

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

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

They all run concurrently

yes, we run linters on changed files using husky, unit tests would take too long to run everything

I dare you

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

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.

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

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.

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

13 min is the longest worker, average check is maybe 5-10 minutes

federal government

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?

A lot of

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.

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

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