I'm developing a web app in PHP where part of the code I'm developing for it will also be used in the tests. I'm not sure how to handle this. That code in question is an abstraction to communicate with eBay's soap/xml API.

I hope the following makes sense...Apologies for another long question!!

Specifically I'm writing an eBay management system that has a GUI which automates eBay processes. I'm using test driven development, and my first acceptance test has highlighted this quandary.

My first feature will show the user a list of orders placed. And the test will first, using Ebay's API, upload an auction in eBay's sandbox, then using a test customer, purchase an item on his behalf, and finally, it will test that the user of my software will see that purchased item in the GUI (which the app will have done by getting order history from eBay's API.

Initially I was going to write a set of objects that provide the app with an object oriented API for interracting with eBay, and have this as part of the application code, so not particularly re-usable. Or at least, not really packaged up in any kind of way, besides good OO principles. But if I continue with this plan, the test scripts would have to "borrow" the source code in the tests, and add functionality to the eBay portion of my code which would only be used in the tests, since it overlaps in part, and not in other parts. (The eBay authentication and similar is a common requirement for the app and the tests, but the other API calls at least to start with do not overlap). If I follow this idea, the problem is I don't know how I should treat the parts of the eBay code that only the tests use; should I write unit/integration tests for those, even though they're only used by the acceptance/integration app tests? Or would the act of using those test-only eBay module features in tests to test app-only eBay module features be enough to act as sufficient tests in case I decide to use the test-only eBay module features in the application?

I was considering extracting the eBay code into a totally separate project (e.g. using composer, and putting it in a separate repository). Then importing the whole thing firstly into the test directory, and also duplicating it in the app's source directory. Then adding features as needed (by the test or the app), and unit/integration testing all aspects of the eBay module equally, even if some aspects are only used by the app, and others only by the app's tests. But then I think the same issue would still apply!! The module's tests would need to use parts of the module to perform the tests on other parts of the module!

有帮助吗?

解决方案

It seems like a fairly classical testing scenario. The solution is to test both the ebay abstraction by integration testing against ebay. You don't want to do this everywhere as it will slow down all your tests so keep it to a minimum.

When you are fairly sure that the abstraction works you can replace it with a mock when testing the rest of your code. Then you just assert that the correct method was called on the mock and call it a day.

许可以下: CC-BY-SA归因
scroll top