Anti-Pattern: Client team tests server interface

You’ve got your web site purring along serving customers and generating revenue. Things are swell. Then you decide that you want to expose some of your functionality via an API (hopefully RESTful) that a mobile application can consume.

So, you setup a Server Team to develop the API. But, since you’re not sure what the usage will be, you decide to save a little scratch by having the Client Team that is building the mobile application test the interface. “After all,” you think to yourself, “the Client Team will be consuming the API, so they might as well build the test app while they’re at it.”

This makes sense, right? After all, the Client Team can’t sign off until the whole integrated system works properly anyway, so they can find the bugs. Besides, maybe they aren’t going to use the entire API: they’ll only test what they’ll use, saving the server team from having to do so.

This is what makes this an anti-pattern: on its face, this might sound like a good idea. But, it’s a really, really bad way to go about building and testing an API.

Here’s how this approach usually works out:

Server Team: Try it now.

Client Team: It’s not working (here’s what we’re getting).

Server Team: Try it again.

Client Team: It’s still not working.

Server Team: Try it again.

Client Team: Still no joy.

And so on.

Now imagine this when the two teams are separated by a few time zones and only have 4 hours a day to work with each other. The time to resolve an issue can be enormous.

This is also a morale killer for the Client Team. There’s nothing they can do to fix the issue. All they can do is report problems. You’ve just taken your (probably expensive) client developers and used them as entry-level QA personnel. How much money are you saving again?

A much better approach is to have each team, no matter what they’re building, be responsible for the design, construction, testing, and on-going maintenance of the system they’re responsible for. If you do so, you’ll realize the following benefits:

  1. Issue resolution times drop. Often, a single developer can test and resolve an issue.
  2. Client team morale improves: They are more assured that the server team is taking responsibility for their work, and not just “throwing it over the fence”.
  3. Software quality improves: Before the Client Team is ever exposed to the server implementation, it has been tested. This can be further enhanced by the addition of automated integration testing where the server team uses tools to check the correctness of their work.

What about the argument that we can save some time if the Client Team only tests the part of the API they’re using? Here’s a counter question: what about the time you can save by not having the Server Team build something no one needs in the first place? Remember, APIs can be versioned and enhanced after they ship.

Let me know if you disagree with my take. Even better, if you have an experience where this pattern actually worked well for you, please share.


© 2009-2024 Tim Vercruysse. All rights reserved.