One thing I’ve noticed since I started working with Rust is that Test-Driven Development (TDD) has become much more feasible. As a developer who is “absentminded by default,” I highly value tests. However, if the feedback cycle is slow, it becomes prohibitively expensive to test everything. This is likely why unit tests are often favored over integration tests: they are more precise, faster to execute, and make rapid round-trip testing more achievable.

Another point is that Rust, being a statically typed language, requires far fewer unit tests than dynamic languages. Traditionally, unit tests are used to validate “input consumption” (ensuring input is processed correctly) and “well-formed output” (verifying that the output meets requirements under specific conditions). In Rust, many of these input-output concerns are resolved at compile time through the use of expressive types like structs and enums.

For these reasons, I find myself more inclined toward integration tests that reflect real-world requirements, rather than focusing solely on unit tests in artificial settings.