Welcome to the Treehouse Community
The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.
Not sold! The end user does not care whose fault it is!
I am not sold that it is a good idea in testing to replace the actual API interface with what the programmer THINKS the API documentation should mean.
The API writer and the programmer having different ideas about what the documentation means is a whole class of common bugs. Not testing to the actual implementation will result in all these bugs being undetected. Even if you are right about one of these disputes, being right will not help you.
API s being written in English or other natural language can result in ambiguities that are difficult to resolve. It could take nine Supreme Court Justices in black robes, arguing about what the meaning of "is is" to resolve such a dispute. In any case, it does not matter, the end user will blame you the programmer for not detecting such a discrepancy.
You can not file a bug report on API problems that you never detected.
The Idea that you can avoid problems by substituting your idea of what the API is for what it actually is is seriously flawed.
Craig DennisTreehouse Teacher
Hi Paul Elliott !
Not sure exactly what you are referring to here, I was showing how to mock or stub out parts of the application to thoroughly test one portion of the code, I wasn't suggesting to not test the other parts eventually. I was trying to show how to isolate parts and not re-test what has already been tested.
I did suggest not to test specifically was things that couldn't break, like getters and setters.
Are you referring specifically to this video or other parts of the course?
Paul Elliot, you are missing the fact that Craig was demonstrating how to isolate and test a component separately from the 3rd party api it was depending upon. Nothing is stopping you from testing the 3rd party api in another set of tests to assure that you are understanding its behaviour and its fidelity to documentation.
When the programmer replaces the API with a simulated API, that works according to his own understanding of the API docs, a whole class of bugs can get missed. Those bugs caused by the actual behavior of the API being different from what the programmer thinks it is. As I pointed out, it does not matter whose fault this is.
I can not now again review the video, but at one point I believe, you stated that one advantage of this approach, is that the programmer does not have to take responsibility for API bugs. The API should have its own tests you said. But what if the API tests were written by someone with a different understanding of the meaning of the API docs? Those test will pass. But the behavior of the API will still be different than what the programmer expects. If the programmer does not test for the actual API behaving as he expects this class of bugs will me missed.
The problem is with the docs being written in English, it is not clear what is a API bug, and what is a programmer misunderstanding bug. This class of bugs should be tested for. I can not think of any way other that testing against the actual API to do this.