3 ms·

> If I try to call a third party library method in a language with a sane type system (like C# or Rust) that returns a string and attempt to assign that value t

> If I try to call a third party library method in a language with a sane type system (like C# or Rust) that returns a string and attempt to assign that value to an int, it won't even compile. You're assuming that for instance the library is correctly setup and won't crapout because a system requirement is not met. Or that no other external factor will interfere with the result (e.g. your library is hooked to an API) Compile time checks will be against a declared interfaces, not the actual library built outside your project. To me that's the kind of issues where having a test coverage really helps, a lot more than just checking that mocks and interfaces match each other (to show my hand, I prefer dynamic languages, so interfaces will rarely fail and many edge cases can be simply be coerced into a generic path, so the real scary stuff is when the rubber meets the road and expectations meet reality)

HideousKojima 2y ago
>You're assuming that for instance the library is correctly setup and won't crapout because a system requirement is not met. Or that no other external factor will interfere with the result (e.g. your library is hooked to an API) Correct, and if that isn't the case then that's a problem with the library, not my code. In C# I've had none of the issues you just mentioned with libraries, with the exception of ones that expect some specific native DLL to be present that the C# library calls into. And unit testing won't save you from that issue because the system you're running your tests on isn't the same as the system prod is running on. To be frankly honest I question how much you know/understand about languages with strong type systems based on your comments.