[dylandrop]

So you're saying that static/strong typing == program future proofing? I guess what I'm trying to say is that even if your application or program is written in a statically typed language doesn't mean that someone can't screw something up when adding on new materials down the road, and having test suite backing you up is always a necessity.

Say you wanted to write a web application in Go, and you wanted to change your login system... Now it may be just me, but having a test suite to determine where you'd have breakages would DEFINITELY be handy in overhauling your login. Doesn't matter that it's statically typed.

[redbad]

I am absolutely not arguing that static/strong typing obviates the need for testing. Unit and integration tests absolutely have a place in statically-typed languages, and it is precisely as you describe: to ensure functional and business-level requirements.

Notice that I said "ensure", and not "describe" or "define". Because I think that's the disconnect. When you come from a dynamically-typed language background, I think you're more apt to believe your testing needs to describe/define your contracts, because you don't have a type system to leverage. But if you _do_ have a type system to leverage, the pathological context that justifies e.g. BDD is no longer valid, and tools like Ginkgo -- enabling "descriptive tests that can act as effective documentation" -- therefore don't make much sense. To me.