Right, so this is the part where I get to sound like a smart ass, because I snuck a “tons of” into there.
What you do always need, is tests serving as a specification of the intended behavior, to document it for your team members and your future self.
But the thing that static typing is an alternative to, is integration tests for many code paths. For example, in dynamic languages you have no reassurance that a call to your database library still works, unless you have an integration test which actually calls into the database. Similarly, you hardly know whether the many error-handling code paths are working, unless you write tests for those, too.
In static languages, we don’t test this stuff outside of the specification-like integration tests, because the database library and the error handling library are already separately tested, and the type system ensures that we interface with them correctly.
Yeah, the alternative to static typing is to write tons of unit tests, which definitely adds a lot more code to your codebase.
That’s not an alternative, you always need tests
Right, so this is the part where I get to sound like a smart ass, because I snuck a “tons of” into there.
What you do always need, is tests serving as a specification of the intended behavior, to document it for your team members and your future self.
But the thing that static typing is an alternative to, is integration tests for many code paths. For example, in dynamic languages you have no reassurance that a call to your database library still works, unless you have an integration test which actually calls into the database. Similarly, you hardly know whether the many error-handling code paths are working, unless you write tests for those, too.
In static languages, we don’t test this stuff outside of the specification-like integration tests, because the database library and the error handling library are already separately tested, and the type system ensures that we interface with them correctly.