A dynamically typed language like Ruby gives us great freedom to do cool stuff, but that freedom comes at a cost. As developers writing code in a dynamic typed language we need to be conscious that that freedom comes with more responsibility. This means Ruby gives us enough rope for us to hang ourselves.
When using dynamically typed languages we are less confident of the correctness of the code. This doesn't mean we should use statically typed languages, at least not just for that reason, as Alan Kay said: *"I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing."*
We could consume a huge amount of time covering our code with tests to have a grade of certainty similar to the one we would have using a statically typed language, that's not only unpractical but it's not worth it. That's where **contract tests** come to the scene, they are fast, reusable and most important allow us to leverage dynamically typed languages awesomeness, such as duck-typing. I've always liked making Barbara Liskov happy and using contract tests allows me to do so.
This talk is about writing beautiful contract tests, the ones that are readable, allows us to save time and be more confident about our codebase while using the language we all love.
December 03, 2013 @ 03:59:09 am UTC