The Pragmatics of TDD

Re:The Pragmatics of TDD by jbaudanza on Wednesday March 06, 2013 @01:14PM (#5332721)

I usually don't write tests for frameworks, databases, web-servers, or other third-party software that is supposed to work. I mock these things out, and test my code, not theirs.

If your software has a dependency on a third party component, then you should include that component in your tests. It's not about testing the component, it's about testing your integration with that component. For example, if you upgrade that component, and the API changes in a way that breaks your integration, you want your test suite to break as well.

Sometimes if a component is too slow or requires network access, you have to mock it out. But as a general rule, it's best to leave your dependencies in place.

[ Parent | on HN ]

Re:The Pragmatics of TDD by azurelogic on Wednesday March 06, 2013 @01:33PM (#5332867)

This gets into the differences between unit testing and integration testing. Sometimes it is worth just making sure that your repository class can actually insert, find, and delete data. It's just a different part of the "testing pyramid" (http://watirmelon.com/tag/software-testing-pyramid/)

[ Parent | on HN ]

Re:The Pragmatics of TDD by jbaudanza on Wednesday March 06, 2013 @02:14PM (#5333162)

A unit's dependency is part of that unit. If a unit test mocks out all the dependencies, that test is running in a fantasy world.

[ Parent | on HN ]