Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Java Unit Testing in Java What to Test What Not To Test

Posted by Paul Elliott
Paul Elliott
2,882 Points

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.

3 Answers

Craig Dennis
STAFF
Craig Dennis
Treehouse Teacher
Craig Dennis
Craig Dennis
Treehouse 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?

stormystormy
stormystormy
779 Points
stormystormy
stormystormy
779 Points

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.

Paul Elliott
Paul Elliott
2,882 Points
Paul Elliott
Paul Elliott
2,882 Points

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.

Sebastian Röder
Sebastian Röder
13,878 Points
Sebastian Röder
Sebastian Röder
13,878 Points

What you are talking about is known under the terms Integration Tests, Functional Tests or Acceptance Tests. These kinds of tests have different tradeoffs from Unit Tests and supplement them, but do not replace them. Search for the "Testing Pyramid" for details. Unit Tests should still be isolated and fast and only test your own code.

If an external API changes, an Integration Test should fail. You should also try to isolate the external API from your own business logic as good as possible, for example using Design Patterns like Gateway or Proxy.