The problems I experienced with TDD in Rails applications (it's about the only way I'm using Ruby) didn't derive from object orientation or dynamic typing. They came from time and money constraints, especially in those one hour or one day rushes to get a new small functionality into the code base and deliver it into production. If a company has an internal development staff the technical debt can be repaid later on. If a company works with consultants paid by the hour, there might be never enough money to do it. An application with reasonable test coverage can quickly turn into an application with 100% broken tests and weeks of work to fix them all. But this isn't about Ruby or OO, it's about customers and the amount of money they want to spend no matter how good you are at explaining them what's happening to their software.
I have a Rails 3.2/Ruby 1.9.3 application that will be hard to port to Rails 4/Ruby 2.1 because of that. The point of the original post could be that writing that application in Haskell would require less work on tests so we could have less technical debt by now. Maybe. But when integration tests break (originally run with Selenium) because the UI changed so much and there are many new functionalities to test, I don't think the language can help. It's back to having enough budget.
I have a Rails 3.2/Ruby 1.9.3 application that will be hard to port to Rails 4/Ruby 2.1 because of that. The point of the original post could be that writing that application in Haskell would require less work on tests so we could have less technical debt by now. Maybe. But when integration tests break (originally run with Selenium) because the UI changed so much and there are many new functionalities to test, I don't think the language can help. It's back to having enough budget.