[layer8]

It’s fundamentally different. Testing in a dynamic language will never ensure that your variable always holds a string and never a number. Compiling a statically-typed language however does exactly that. This difference is the same for all checks a compiler performs.

It’s important to understand that difference, because otherwise you may think that testing and the static analysis performed by a compiler are interchangeable. They are not.

[FridgeSeal]

> otherwise you may think that testing and the static analysis performed by a compiler are interchangeable. They are not

I agree with you, but I think this is the issue. A lot of people used to working in dynamic languages spend time writing up lots of tests for things that get covered “automatically” in statically typed languages, leading to the confusion you note. This, I’d argue, effects people who “convert” to liking the static language, and to those who think static lands cause only overhead.

[troupo]

> spend time writing up lots of tests for things that get covered “automatically” in statically typed languages

This is mostly down to poor testing culture in general. People end up writing a lot of meaningless unit tests when what you need is integration tests. However, there's very little tooling to help with integration tests (in all languages) as everything is focused on unit testing only.

With proper integration tests you will cover much of what the compiler gives you in statically-typed languages.

[thunky]

I don't think it makes sense to expect integration tests have 100% coverage, which is what you would need.

[troupo]

Nothing is really 100% coverage :)

[a_humean]

Unless you are sqlite, they might actually credibly have 100% coverage.

[serial_dev]

They are not interchangeable but there is an overlap.

For normal code bases, this overlap is relatively small (do not need to validate input types, don't need to automatically convert strings to numbers, convert single items to lists, etc), but as you take advantage of the type system, the overlap can become slightly larger (wrap your types, create separate types for validated values, make impossible states impossible).

Granted, no matter how much of a genius you are with the type system, there will always be place for testing, I hope everybody understands that.

[troupo]

And if your type system is expressive ... you might still need to write tests to make sure that your types are correct and give you back the result you actually want :)

I've seen people build type-level DSLs. Sure they encode a lot of logic in types... but are you sure that logic is correct? :)

[rocqua]

Testing and analysis aren't equivalent, but they can be similar enough in use to be interchangeable.

As an example the approach of 'type correctness through a type checker' and 'type-correctness through integration testing' is largely interchangeable in python. Even though they function very differently.