What do you think about the author's opinion on focusing on integration tests? I am a relatively young developer and face a lot of backlash at my workplace when I prefer writing integration tests to unit tests. Our components have hundreds of unit tests, but things break because the data quality of connected systems is so poor. I always think, you could make most of these problems visible and communicate them to other teams in advance with just sending masses of data sets through the system using automated integration tests. But instead, we spend our time writing unit tests on our poor assumptions and fighting the mess in production.

Every time unit tests pass but it fails in production means you know exactly what kind of test to write next: one that replicates the issue in production. Unit tests are quicker to run which makes iteration easier. Integration tests take longer to execute. They both have their strengths and weaknesses.

Out of curiosity, how long do integration tests take to run for you? I will run e.g. "pytest", which might take a few minutes with a lot of integration tests, but I can also just run "pytest -k test_something" to run a particular integration test that will hit the function I care about, and it will take maybe 20 seconds. Unit tests are faster than that, yeah, but honestly that's a tight enough feedback loop for me to iterate quickly.

On my personal project with 78 integration tests it takes about 2.5min. Test coverage isn't anywhere near complete. I can target individual tests too, but I'm usually testing in browser locally anyway so its the rest of the suite that needs to run to find the unexpected regressions.

Author here, love this comment. Wish I would've wrote more about this loop (thing breaks in production, writing a test so said thing wont break again).

I really wish their was a way to make integration tests run quickly.

I honestly heavily prefer integration tests exactly because unit tests can miss the bigger picture. Search for "two unit tests, zero integration tests" if you'd like an easy-to-digest thing to share with your coworkers.

Don't get me wrong, unit tests are still useful. But someone needs to have the big picture in mind, and say "what happens if a human does this?" and consider all of the disparate component that may be involved in that action.

As a concrete example, don't rely on API requests to say that your microservice is fine. Boot up a full browser with Selenium to act as an actual user and start poking around the frontend. You'll probably say "oh right, I should fix that" at least a few times.

If you knew Rails, why did you choose React and all the complexity that comes with it? Or are you still using Rails?

Great question!

The react ecosystem is pretty great. Chakra UI makes it easy to take out of the box components and piece them together. I'd love to see the new turbo/hotwire stuff catching on and getting a ton of libraries in the future, time will tell.

I also cut a whole paragraph in my article about how great https://vitejs.dev/ is. Makes marrying react and rails a breeze.

Shameless plug, we are having some hiring events this week (basically a webinar where I'll do some live q&a). Would love to have you! https://calendar.google.com/calendar/embed?src=c_jk45i396ab9...

Interesting so the component library is making that decision due to how well built and composable that is?

Would also love to read about the Rails-Vite marriage.

I am no longer seeking employment, having become an investor now, but thank you for the link.

Because a server-rendered website is not always a good fit for a dynamic web app.

Of course. What I meant was, does this site have such dynamic elements?