<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic How much is too much integration testing??? in Integration and Testing</title>
    <link>https://community.developer.cybersource.com/t5/Integration-and-Testing/How-much-is-too-much-integration-testing/m-p/70743#M43476</link>
    <description>&lt;P&gt;ello,&lt;/P&gt;&lt;P&gt;I'm writing an API, and trying to learn all the testing best practices.&lt;/P&gt;&lt;P&gt;I'm current unit testing and and mocking all my components, which is great.&lt;/P&gt;&lt;P&gt;I now want to start integration testing. Should I have per-component integration tests, or just tests for the entire API, treating it as a black box?&lt;/P&gt;&lt;P&gt;For example, I have a queue package that wraps RabbitMQ. Should I put an integration test on this?&lt;/P&gt;&lt;P&gt;Or should I simply have "input requests" and "output requests", and run these against the API itself, ignoring all the inner components?&lt;/P&gt;&lt;P&gt;I'm using Go, and I'm trying to learn by examining the Docker git repo. It seems they do the second sort of testing, but maybe I misinterpreting their code.&lt;/P&gt;&lt;P&gt;By integration testing, I mean testing code that interacts with other live (not mocked!) services, like a queuing service or a database.&lt;/P&gt;&lt;P&gt;Cheers!&lt;/P&gt;</description>
    <pubDate>Fri, 21 Feb 2020 21:32:37 GMT</pubDate>
    <dc:creator>josemackinson</dc:creator>
    <dc:date>2020-02-21T21:32:37Z</dc:date>
    <item>
      <title>How much is too much integration testing???</title>
      <link>https://community.developer.cybersource.com/t5/Integration-and-Testing/How-much-is-too-much-integration-testing/m-p/70743#M43476</link>
      <description>&lt;P&gt;ello,&lt;/P&gt;&lt;P&gt;I'm writing an API, and trying to learn all the testing best practices.&lt;/P&gt;&lt;P&gt;I'm current unit testing and and mocking all my components, which is great.&lt;/P&gt;&lt;P&gt;I now want to start integration testing. Should I have per-component integration tests, or just tests for the entire API, treating it as a black box?&lt;/P&gt;&lt;P&gt;For example, I have a queue package that wraps RabbitMQ. Should I put an integration test on this?&lt;/P&gt;&lt;P&gt;Or should I simply have "input requests" and "output requests", and run these against the API itself, ignoring all the inner components?&lt;/P&gt;&lt;P&gt;I'm using Go, and I'm trying to learn by examining the Docker git repo. It seems they do the second sort of testing, but maybe I misinterpreting their code.&lt;/P&gt;&lt;P&gt;By integration testing, I mean testing code that interacts with other live (not mocked!) services, like a queuing service or a database.&lt;/P&gt;&lt;P&gt;Cheers!&lt;/P&gt;</description>
      <pubDate>Fri, 21 Feb 2020 21:32:37 GMT</pubDate>
      <guid>https://community.developer.cybersource.com/t5/Integration-and-Testing/How-much-is-too-much-integration-testing/m-p/70743#M43476</guid>
      <dc:creator>josemackinson</dc:creator>
      <dc:date>2020-02-21T21:32:37Z</dc:date>
    </item>
  </channel>
</rss>

