[redbad]

Like afandian, I'm a little fuzzy on the particulars of my gut reaction. But it's something along the lines of this: that BDD, or TDD, or test-oriented-development-practice-X didn't emerge from the ecosystems of dynamically-typed languages by accident. Those languages lack an entire class of verification that statically typed languages have by default, and which is actually important. So their practitioners abide tools, idioms, and practices to make up for that deficiency.

Those things aren't all bad, and _some_ of their lessons can be successfully "ported" to languages and ecosystems that don't suffer the same fundamental shortcomings as e.g. Ruby or Python. But when I see developers take e.g. the BDD ethos as axiomatic and just run with it, it makes me feel like they don't really understand what BDD is designed to address. Likewise with hyper-expressive testing DSLs, or the concept of "mocking" as it's normally used.

Forgive the loaded language, but bringing BDD et. al. to languages like Go feels, to me, like cargo-cult development.

[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.

[herge]

Maybe TDD emerged from dynamically typed languages because it is so much easier to write tests in a dynamically typed language?

When testing a statically typed language, you have to jump through a lot of hoops to create mock objects, shims and things like that to satisfy the compiler, especially with legacy code that wasn't written in an easy way to test.