<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 30/07/13 17:05, Ceri Storey wrote:<br>
    </div>
    <blockquote cite="mid:51F7E437.3030106@lshift.net" type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=ISO-8859-1">
      <div class="moz-cite-prefix">(30/07/13 16:30), Tom Anderson wrote:<br>
      </div>
      <blockquote cite="mid:51F7DBFE.1020306@timgroup.com" type="cite">
        <div class="moz-cite-prefix">On 29/07/13 17:51, Ceri Storey
          wrote:<br>
        </div>
        <blockquote cite="mid:51F69D9D.9000704@lshift.net" type="cite">
          <div class="moz-cite-prefix">(29/07/13 17:25), Tom Anderson
            wrote:<br>
          </div>
          <blockquote cite="mid:51F69780.6080602@timgroup.com"
            type="cite">
            <div class="moz-cite-prefix">On 29/07/13 13:40, Matthias
              Radestock wrote:<br>
            </div>
            <blockquote cite="mid:51F662A6.3060006@rabbitmq.com"
              type="cite">...<br>
            </blockquote>
            <br>
            Aha. I didn't realise, that, thanks.<br>
            <br>
            What i'm looking for is a way to get some sort of feedback
            at the sender when a message has been acknowledged by the
            consumer. Given that transient messages are confirmed as
            soon as the message has reached the queue, and persistent
            messages are confirmed as soon as they are written to disk,
            am i right in concluding that there is no way to do this
            with confirms? Is there any other mechanism in RabbitMQ that
            might let me do this?<br>
            <br>
            My real goal here is to write a test for an application of
            ours, to assert that it is only acknowledging messages after
            it has successfully processed them, and not immediately on
            receipt. If anyone has any thoughts on how i might be able
            to do that, i would be very excited to hear them!<br>
          </blockquote>
          For your test, I'd be very tempted to provide an adapter which
          enforces the guarantees you want to make. Then you can have
          tests that:<br>
          <ul>
            <li>For the happy path, asserts that no more messages exist
              on the expected (ie: that a <tt>basic.get</tt> will
              return no messages)<br>
            </li>
            <li>For the failure path, asserts that the sent message is
              available to other consumers once your adapter has
              properly failed and shut down. <br>
            </li>
          </ul>
          <p>Granted, the latter does assume that you can shut down the
            adapter reasonably easily. <br>
          </p>
        </blockquote>
        <br>
        Apologies if i'm being thick, but what do you mean by "adapter"?
        Do you mean code that sits between the application code and the
        AMQP library? Or code that the test can use to take a grip on
        the application code? Or something else?<br>
      </blockquote>
      Yes, sorry, that's it, so it's an interface to external
      infrastructure (in this case Rabbit), that presents itself in
      terms of something relevant to your application. So in my case, I
      tell it what what kinds of job I want to receive, and it would
      call back to another object when there is a job to be done. It's a
      term pulled from Alistair Cockburn's <a moz-do-not-send="true"
        href="http://alistair.cockburn.us/Hexagonal+architecture">Hexagonal

        Architecture</a>, FWIW.<br>
    </blockquote>
    <br>
    Maybe also similar to Nat Pryce's 'simplicator' then:<br>
    <br>
    <a class="moz-txt-link-freetext" href="http://www.natpryce.com/articles/000785.html">http://www.natpryce.com/articles/000785.html</a><br>
    <br>
    The thing is, what i really want to test, because it's the thing i
    have most uncertainty about, is my usage of the RabbitMQ API. That
    would be in the adaptor. So, introducing that adaptor would let me
    write tests around the logic inside the application, but they would
    be rather vacuous, and they would leave the scary bit untested.<br>
    <br>
    It is probably still worth driving a plane of fracture through the
    system above the RabbitMQ API and unit-testing that, though. I can
    then at least be confident that bugs are boxed into the API-using
    code, and then write the best end-to-end integration test i can
    manage, even if it's not rock solid.<br>
    <br>
    tom<br>
    <br>
    <div class="moz-signature">-- <br>
      <p>Tom Anderson | Developer | +44 20 7826 4312 | <a
          href="http://timgroup.com/">timgroup.com</a></p>
      <div style="color:DarkGrey; font-size: small;">
        <p>STATEMENT OF CONFIDENTIALITY: The information contained in
          this electronic message and any attachments to this message
          are intended for the exclusive use of the addressee(s) and may
          contain confidential or privileged information. If you are not
          the intended recipient, please notify Tom Anderson at TIM
          Group at <a class="moz-txt-link-abbreviated" href="mailto:tom.anderson@timgroup.com">tom.anderson@timgroup.com</a> and destroy all copies of
          this message and any attachments.</p>
        <p>TIM Group is the trading name for YouDevise Limited.
          YouDevise Limited is registered in England, No. 3331176.
          Registered office: 3 Copthall Avenue, London, EC2R 7BH.</p>
      </div>
    </div>
  </body>
</html>