pre-integration testing problem

[John Grandy]

This is a higher level question, not specifically a technical one.

I am hoping to find someone who has experience developing an application
that will interface with an external api ( perhaps a web api ) where during
the coding/testing phase it will not be possible for the app under
development to actually call into this api. This could be because the api
is not yet implemented ( or is only partially implemented ), or is not yet
available due to higher-level project issues ( multi-vendor coordination,
political, legal, etc. ) , or is available but only at bandwidth/reliability
markedly below anticipated production levels, etc.

The bottom line is that it is impossible to incorporate this api within the
development environment. Only at time of deployment will it be possible for
the app to actually call into the external api.

What is available is the external api's interface spec. Also known is the
expected I/O for various use-cases -- however, it cannot be assumed this is
accurate.

Some options I can think of are :

1. Write a proxy api in the project's language that simulates the behavior
of the real-world api ( as much as possible ).

2. Write an "exploration test harness" that right now will be delivered to
the production environment to run against the actual api and simulate the
calls made in common use cases. This exploration test harness is
lightweight and is designed so as to easily integrate into the existing
target production environment. It is exploratory in the sense that it is
meant to be expanded/refined as more is learned about the behavior external
api.


I realize this is a somewhat vague, indeed rather partial statement of the
problem, but perhaps there is someone out there with experience in this
scenario who has some thoughts ...

Thanks.

 

[Family Tree Mike]

This is a higher level question, not specifically a technical one.

I am hoping to find someone who has experience developing an application
that will interface with an external api ( perhaps a web api ) where during
the coding/testing phase it will not be possible for the app under
development to actually call into this api. This could be because the api
is not yet implemented ( or is only partially implemented ), or is not yet
available due to higher-level project issues ( multi-vendor coordination,
political, legal, etc. ) , or is available but only at bandwidth/reliability
markedly below anticipated production levels, etc.

The bottom line is that it is impossible to incorporate this api within the
development environment. Only at time of deployment will it be possible for
the app to actually call into the external api.

What is available is the external api's interface spec. Also known is the
expected I/O for various use-cases -- however, it cannot be assumed this is
accurate.

Some options I can think of are :

1. Write a proxy api in the project's language that simulates the behavior
of the real-world api ( as much as possible ).

2. Write an "exploration test harness" that right now will be delivered to
the production environment to run against the actual api and simulate the
calls made in common use cases. This exploration test harness is
lightweight and is designed so as to easily integrate into the existing
target production environment. It is exploratory in the sense that it is
meant to be expanded/refined as more is learned about the behavior external
api.


I realize this is a somewhat vague, indeed rather partial statement of the
problem, but perhaps there is someone out there with experience in this
scenario who has some thoughts ...

Thanks.

This is not on the surface a csharp question, but...

With option 1, I don't know why you added "... in the project's
language...". With a remote API, you don't particularly care what it
was written in, if you even ever know it. Option 1 seems possible
though if you tasked to write an app to a solid API specification. I
would say it does not have to "simulate the behavior" of the API, but
rather just take the same inputs, provide some reasonable outputs, and
provide perhaps the typical delays that are expected.

Option 2 would be good for the remote team, if you are at all working
with them. If you are not working "with" them to specify the
connections, then you are probably best going with option 1.

 

[John A Grandy]

Hi Mike, and thanks for the response.

Yes, not specifically C# but where else to post ? This newsgroup has the
largest contingent of experienced developers.

Good idea re adding simulated delays.

Why do you think language does not matter ? Let's say the external web api
is Java/WebSphere/Linux. If I write the proxy api in C#/ASP.NET/IIS/Windows
( even assuming a 100% accurate spec ) would I not potentially introduce
some technology-specific anomalies ?

 

[Family Tree Mike]

Hi Mike, and thanks for the response.

Yes, not specifically C# but where else to post ? This newsgroup has
the largest contingent of experienced developers.

Good idea re adding simulated delays.

Why do you think language does not matter ? Let's say the external web
api is Java/WebSphere/Linux. If I write the proxy api in
C#/ASP.NET/IIS/Windows ( even assuming a 100% accurate spec ) would I
not potentially introduce some technology-specific anomalies ?

John,

Sorry, I was thinking more of a .Net Web Service context, and that you
should not care that it was a C# or VB code behind it. That is a
different question than the Web Service platform.