Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><a href="http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html" rel="noreferrer">First of all</a>, <a href="http://test-driven-development.com/2011/08/07/do-not-mock-third-party-classes/" rel="noreferrer">don't mock external APIs</a>. Why? <a href="http://www.mockobjects.com/2007/04/test-smell-everything-is-mocked.html" rel="noreferrer">Cos you don't own them</a>.</p> <p>The ideal solution for your problem seems to be what you started describing. You should create an interface in your project that <strong>you own</strong>, that will represent the external service.</p> <pre><code>public interface CalculatorService { int add(int a, int b); } </code></pre> <p><strong>This will be your <em>border</em> for testing.</strong> All your UNIT and ACCEPTANCE tests should run against a mock or stub of <code>CalculatorService</code>. They will be fast. You can do that since it is you who defines that <strong>contract</strong> (what that interface actually means).</p> <p>Later, you will have an implementation that goes to that remote HTTP rest service:</p> <pre><code>class RemoteRestCalculator implements CalculatorService { public int add(int a, int b) { // call the remote service in here } } </code></pre> <p>You need to test this <strong>contract</strong> (border). So you will write integration tests just for the <code>RemoteRestCalculator</code>. You can also have couple of end-to-end tests that run application with the <code>RemoteRestCalculator</code> to test the wiring, etc.</p> <p><strong>Now, to answer you question,</strong> how to test that <code>RemoteRestCalculator</code>?</p> <ol> <li><strong>Ideally you would deploy an instance of the real http rest service in your testing environment, point it to a testing database, etc.</strong> So you talk to the guys that own that service, they provide you with the *.war file and you deploy it locally with test database etc. <strong>Sometimes they do it for you, a "sandbox" deployment of that service.</strong>. <em>Then you write test for <code>RemoteRestCalculator</code> that run against that instance.</em></li> <li>Another solution is similar to what you mentioned. Create a "http rest service simulator". Then deploy it locally. <strong>The trick is that you will have to replicate the real service behaviour for all functionalities you use</strong> in that simulator. So, the simulator "add" method will have to behave the same as the real one. There is a lot of strong pros and cons to this solution. <em>Then you write test for <code>RemoteRestCalculator</code> that run against that simulator.</em></li> <li>There is a mid-way solution that is used quiet commonly in the industry. You just run all your tests against the local test deployment of the real service (or sometimes the simulator). <strong>The test suite can be very slow unfortunately in this case when you have lots of tests. Not recommended.</strong> <a href="http://dan.bodar.com/2012/02/28/crazy-fast-build-times-or-when-10-seconds-starts-to-make-you-nervous/" rel="noreferrer">Further reading about making builds go faster</a>.</li> <li>There is one more solution used commonly which is not recommended in most cases. You create a "http rest stub class", that is used kind of like mockito mock but it always talks via http. So usually it would start a http server and you would prime it before use use it. It has a lot more disadvantages than advantages. The biggest disadvantage is that the behaviour of the service (external dependency) is scattered across many tests in your application. <strong>Not recommended.</strong></li> </ol>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload