Re: Services, API keys, tests, etc.

I do much the same. I add a file called TestConfiguration.php.dist with default settings for tests (e.g. whether BCMath/GMP are enabled, and other user-specific data) Any user can override this by creating the same file (without the .dist ending) and personalise it. From there it's just a matter of formatting tests (don't know if you use PHPUnit/or something else) and marking certain tests as skipped if the data is not available. Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ----- Original Message ---- From: Clay Loveless <clay@killersoft.com> To: PEAR developer mailinglist <pear-dev@lists.php.net> Sent: Wednesday, September 19, 2007 2:28:59 AM Subject: Re: [PEAR-DEV] Services, API keys, tests, etc. On Sep 18, 2007, at 5:56 PM, Joe Stump wrote: > Now, both of these services have both public'ish API keys and > secrets. The problem I have is publicly exposing my API keys and > secrets via my package's tests. With Facebook it's minimized > because you have to add the Services_Facebook PEAR application to > your profile (I've created a junk account specifically for the > tests), but Flickr is a bit more open I think, though you'd need to > give the package access to your Flickr account before write > operations could happen. > > I suppose I could create a junk Flickr account and do the same > thing I did with Facebook ... > > Thoughts? My plan for this sort of thing -- I'm running into a similar issue with unit tests for the new VersionControl_SVN package -- is to have a tests directory that contains a README, with instructions on how the tests directory needs to have "sensitive.ini" or some other sort of config file in it. That README defines what the config file needs to have, such as keys, shared secrets, etc. in order for tests to run properly. Then you commit and release the package with everything *but* your sensitive config information. Those who really want to run tests can read the README and configure their own local environment accordingly to run the tests. Might be worth an RFC for a "test/secrets.ini" proposal, so that there's one place that all packages which have tests that need some sort of account information can look for that info. secrets.ini: [VersionControl_SVN] login: clay password: foo [Services_Flickr] api_key: 1234456778889 [Services_Facebook] apikey: 12356789 .. and so on. The test can load parse_ini_file('@tests@/ secrets.ini', true) and pick out the credentials needed by the package. Given the rise of web service packages that need exactly this sort of thing, this sounds better to me with every keystroke. :) -Clay -- Killersoft.com -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php ____________________________________________________________________________________ Check out the hottest 2008 models today at Yahoo! Autos. http://autos.yahoo.com/new_cars.html