Integrating ExpressionEngine with Third-Party APIs : Part 4

Published on 26th July, 2011 by Stephen Lewis

This is the fourth (and final) post in a short series of articles. If you haven’t read parts one, two, and three yet, you should do so before proceeding.

Whereas the previous instalment was concerned with uncovering inconsistencies in the target API, this post is all about testing your code; what you need to test, and how.

Full disclosure

I’m a big fan of Test-Driven Development, as those who endured my EECI 2010 talk on the subject will attest.

Unit testing and TDD are huge topics, and I’ve made no attempt to cover them in this post. If you’re completely unfamiliar with such things, the following resources should get you started:

• Wikipedia’s unit testing page provides a decent overview of unit testing.
• Wikipedia’s Test Driven Development page does a similarly good job for TDD.
• “Test-Driven Development: By Example” is the best introduction to TDD that I’ve come across.
• If you prefer to learn by watching, the Pragmatic Programmers have a series of TDD screencasts by Kent Beck, the author of “Test-Driven Development: By Example”.

Basic requirements

Whatever your chosen testing strategy, it must satisfy the following basic criteria:

1. Testing must be efficient.
2. Testing must be effective.
3. Testing must be (or at least have the potential to be) comprehensive.

Efficient testing

Efficient testing is:

• Quick and easy to run.
• Non-destructive.
• A natural part of your workflow.

Quick and easy

Running your tests should not require any preparation time. If your testing strategy requires that your reset a bunch of database tables before each test, or fiddle with configuration files, it is neither quick nor easy.

This is vitally important, because testing that is not quick and easy soon becomes no testing at all.

Non-destructive

Every test you write should leave the world as it found it. Just as your tests shouldn’t require any preparation time, so they should not require any recovery time.

If you find yourself recreating rows in the exp_members table every time you test your delete_member method, it’s time to rethink your approach.

Natural workflow

A couple of keystrokes, or a simple click of the mouse, should be all it takes to run all of your tests. Once again, when it comes to testing, inertia is your mortal enemy.

Effective and comprehensive testing

Your chosen testing strategy should allow you to test edge-cases as easily as common scenarios.

Equally, it should enable you to test “destructive” actions (such as delete_member) and non-destructive actions (get_member) with similar ease.

Conclusion

And so, as the hamster of time loses its footing on the exercise wheel of fate and cartwheels helplessly towards the water bottle of destiny, and the seagull of eternity circles the freshly-washed car of hope, it is time to draw this short series of articles to a close.

Before I turn and flounder my way back towards the shoreline, leaving you bobbing helplessly in a sea of unfamiliar APIs, allow me to throw you a lifebelt that may keep you afloat in these treacherous waters: RESTful Web Services is a splendid book covering APIs in general, and RESTful APIs in particular; its only failing being a lack of Humphrey Lyttelton references.