Sandbox issues is believable. However, them not deprecating the live APIs is not as believable. (Ex. request v53 but they serve the response with v54, something that would break production code is really rare or non-existent with most APIs). You were implying that them not deprecating the live API is more likely to happen then a network failure, as per my understanding.
The only thing my statement implied is that sometimes even bright people are mistaken or jump to conclusions. Even Martin Fowler or Donald Knuth make mistakes & readily admit it. I was just asking for further clarification though, not even implying that you were mistaken. Anyways thanks for clarifying.
Testing remote API classes
Moderator: General Moderators
Re: Testing remote API classes
Well, I understand now what you meant, but you made it sound like it was a question of belief rather than facts. I apologize for the misunderstanding.
Yes, it's true that the problems I encountered were mostly on the sandbox rather than the live site. I would never allow issues to go unresolved to the production site that uses the live API (at least - none that I know of), and after pushing it live I always made several small transactions to confirm everything is working. For those reasons I can't really know if those problems exist on both the sandbox and live API modes. It made testing difficult, but for now I have dealt with all the cases I'm aware of.
Yes, it's true that the problems I encountered were mostly on the sandbox rather than the live site. I would never allow issues to go unresolved to the production site that uses the live API (at least - none that I know of), and after pushing it live I always made several small transactions to confirm everything is working. For those reasons I can't really know if those problems exist on both the sandbox and live API modes. It made testing difficult, but for now I have dealt with all the cases I'm aware of.
Re: Testing remote API classes
Its for reasons like this that manual testing will always be needed. Blame is due to me for misunderstanding you as well.
What I would do is use knowledge you gain during manual testing, to create your own sandbox that you have control over (basically a stub server, that maybe has some network capabilities as well). I would probably have a different stub class for each scenario you are writing a test for. Your unit tests would hit the stub server, and your functional tests would be the ones that hit the stub server over the network (localhost).
What I would do is use knowledge you gain during manual testing, to create your own sandbox that you have control over (basically a stub server, that maybe has some network capabilities as well). I would probably have a different stub class for each scenario you are writing a test for. Your unit tests would hit the stub server, and your functional tests would be the ones that hit the stub server over the network (localhost).
Re: Testing remote API classes
The problem for me with that approach is that only implements what I know (and for that I have tests already). I would still need to make http requests to the paypal server (both sandbox and live) when I make changes to test that it still works, but I guess there's no helping that
Re: Testing remote API classes
Yeah I don't think there's anyway around that. Also understand, the reason TDD advocates writing the tests in the first place is not primary to "test" that it works, but rather test that changes you are making don't alter the behavior unless you want them to. So I think you still get all the benefits that TDD has to offer.