For the longest time, I&#39;ve been working with gigantic applications where testing was slow because everything depended on the whole application running.<div><br></div><div>Even if you had an isolated, granular test that didn&#39;t need a database, a database would be created for you. And you would have to wait for it.</div>

<div><br></div><div>Right now things are different in my current environment. A few of the core functionalities of this application have been decoupled and are now independent HTTP services. This is great for modularity, but poses a problem for testing.</div>

<div><br></div><div>The current approach for running a test in application Foo that talks to HTTP service Bar, is to run the Bar HTTP service as part of some setup.</div><div><br></div><div>This seems straightforward, it is only an HTTP service after all, but what happens when that service become expensive to run? What if it needs a database and other things in order to run properly? What if it gets to the point where you need to wait for several seconds just to bring it up for your test that takes 0.01 to complete?</div>

<div><br></div><div>If Bar keeps getting updated, having Foo test Bar against a number of versions is a pain multiplier.</div><div><br></div><div>I&#39;ve heard a few ideas, but I am interested in what you guys have experienced as a good approach. Here are the list of things I&#39;ve heard, some of them include ones that I am using:</div>

<div><br></div><div>1. Bring the real HTTP service with whatever dependencies it needs to test against it.</div><div>2. Mock everything against the HTTP service with canned responses</div><div>3. Use #1 for recording answers and run subsequent tests against it using the recorded responses.</div>

<div>4. Have &quot;official&quot; mocks from the HTTP service where behavior is maintained but setup is     minimum.</div><div><br></div><div>All of the above have some caveat I don&#39;t like: #1 is slow and painful to deal with, #2 will always make your tests pass even if the HTTP service changes behavior, #3 only works in certain situations and you still need at least a few slow setups and deal with a proper setup of the whole HTTP service, #4 is a problem if the HTTP service itself wasn&#39;t crafted with 3rd party testing in mind, so that mocks can be provided without reproducing the actual app again.</div>

<div><br></div><div>Any ideas or suggestions are greatly appreciated!</div><div><br></div><div><br></div><div>-Alfredo</div>