[scapegoat2]

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.

[cosmotic]

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.

[gaganyaan]

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.

[cosmotic]

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.

[adenta]

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.

[gaganyaan]

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.

[adenta]

Author here! Love seeing younger developers think critically about an organization's bottlenecks. Shameless plug, but if the article was interesting, you should totally come to one of our hiring events this week: https://calendar.google.com/calendar/embed?src=c_jk45i396ab9...