<p>I know the so-called textbook definition of unit tests and integration tests.  What I am curious about is when it is time to write unit tests... I will write them to cover as many sets of classes as possible.</p>

<p>For example, if I have a <code>Word</code> class, I will write some unit tests for the <code>Word</code> class.  Then, I begin writing my <code>Sentence</code> class, and when it needs to interact with the <code>Word</code> class, I will often write my unit tests such that they test both <code>Sentence</code> and <code>Word</code>... at least in the places where they interact.</p>

<p><em>Have these tests essentially become integration tests because they now test the integration of these 2 classes, or is it just a unit test that spans 2 classes?</em></p>

<p>In general, because of this uncertain line, I will rarely actually write integration tests... or is my using the finished product to see if all the pieces work properly the actual integration tests, even though they are manual and rarely repeated beyond the scope of each individual feature?</p>

<p>Am I misunderstanding integration tests, or is there really just very little difference between integration and unit tests?</p>

[{'answer_id': 10756, 'author': 'DevelopingChris', 'author_id': 1220, 'author_profile': 'https://Stackoverflow.com/users/1220', 'pm_score': 4, 'selected': False, 'text': '<p>using Single responsibility design, its black and white. More than 1 responsibility, its an integration test. </p>\n\n<p>By the duck test (looks, quacks, waddles, its a duck), its just a unit test with more than 1 newed object in it.</p>\n\n<p>When you get into mvc and testing it, controller tests are always integration, because the controller contains both a model unit and a view unit. Testing logic in that model, I would call a unit test.</p>\n'}, {'answer_id': 10758, 'author': 'Jon Limjap', 'author_id': 372, 'author_profile': 'https://Stackoverflow.com/users/372', 'pm_score': 4, 'selected': False, 'text': "<p>I think when you start thinking about integration tests, you are speaking more of a cross between physical layers rather than logical layers.</p>\n\n<p>For example, if your tests concern itself with generating content, it's a unit test: if your test concerns itself with just writing to disk, it's still a unit test, but once you test for both I/O AND the content of the file, then you have yourself an integration test. When you test the output of a function within a service, it's a unit-test, but once you make a service call and see if the function result is the same, then that's an integration test.</p>\n\n<p>Technically you cannot unit test just-one-class anyway. What if your class is composed with several other classes? Does that automatically make it an integration test? I don't think so.</p>\n"}, {'answer_id': 10760, 'author': 'Christian Hagelid', 'author_id': 202, 'author_profile': 'https://Stackoverflow.com/users/202', 'pm_score': 2, 'selected': False, 'text': "<p>Unit testing is testing against a unit of work or a block of code if you like. Usually performed by a single developer.</p>\n\n<p>Integration testing refers to the test that is performed, preferably on an integration server, when a developer commits their code to a source control repository. Integration testing might be performed by utilities such as Cruise Control.</p>\n\n<p>So you do your unit testing to validate that the unit of work you have built is working and then the integration test validates that whatever you have added to the repository didn't break something else.</p>\n"}, {'answer_id': 10761, 'author': 'Lance Fisher', 'author_id': 571, 'author_profile': 'https://Stackoverflow.com/users/571', 'pm_score': 2, 'selected': False, 'text': "<p>I think I would still call a couple of interacting classes a unit test provided that the unit tests for class1 are testing class1's features, and the unit tests for class2 are testing its features, and also that they are not hitting the database.</p>\n\n<p>I call a test an integration test when it runs through most of my stack and even hits the database.</p>\n\n<p>I really like this question, because TDD discussion sometimes feels a bit too purist to me, and it's good for me to see some concrete examples.</p>\n"}, {'answer_id': 10762, 'author': 'John Smithers', 'author_id': 1069, 'author_profile': 'https://Stackoverflow.com/users/1069', 'pm_score': 1, 'selected': False, 'text': "<p>A little bit academic this question, isn't it? ;-)\nMy point of view:\nFor me an integration test is the test of the whole part, not if two parts out of ten are going together.\nOur integration test shows, if the master build (containing 40 projects) will succeed.\nFor the projects we have tons of unit tests.\nThe most important thing concerning unit tests for me is, that one unit test must not be dependent on another unit test. So for me both test you describe above are unit tests, if they are independent. For integration tests this need not to be important.</p>\n"}, {'answer_id': 10769, 'author': 'Michael Neale', 'author_id': 699, 'author_profile': 'https://Stackoverflow.com/users/699', 'pm_score': 2, 'selected': False, 'text': '<p>I do the same - I call them all unit tests, but at some point I have a "unit test" that covers so much I often rename it to "..IntegrationTest" - just a name change only, nothing else changes. </p>\n\n<p>I think there is a continuation from "atomic tests" (testing one tiny class, or a method) to unit tests (class level) and integration tests - and then functional test (which are normally covering a lot more stuff from the top down) - there doesn\'t seem to be a clean cut off. </p>\n\n<p>If your test sets up data, and perhaps loads a database/file etc, then perhaps its more of an integration test (integration tests I find use less mocks and more real classes, but that doesn\'t mean you can\'t mock out some of the system).</p>\n'}, {'answer_id': 10817, 'author': 'Rob Cooper', 'author_id': 832, 'author_profile': 'https://Stackoverflow.com/users/832', 'pm_score': 6, 'selected': False, 'text': "<p>My 10 bits :D</p>\n\n<p>I was always told that <strong>Unit Tests</strong> is the testing of an <em>individual component</em> - which should be exercised to its fullest. Now, this tends to have many levels, since most components are made of smaller parts. For me, a <em>unit</em> is a functional part of the system. So it has to provide something of value (i.e. not a method for string parsing, but a <em>HtmlSanitizer</em> perhaps).</p>\n\n<p><strong>Integration Tests</strong> is the next step up, its taking one or more components and making sure they work together as they should.. You are then above the intricacies of worry about <em>how</em> the components work individually, but when you enter html into your <em>HtmlEditControl</em> , it somehow magically knows wether its valid or not..</p>\n\n<p>Its a real movable line though.. I'd rather focus more on getting the damn code to work full stop ^_^</p>\n"}, {'answer_id': 10861, 'author': 'grom', 'author_id': 486, 'author_profile': 'https://Stackoverflow.com/users/486', 'pm_score': 3, 'selected': False, 'text': '<p><a href="http://en.wikipedia.org/wiki/Unit_testing" rel="noreferrer">Unit Testing</a> is a method of testing that verifies the individual units of source code are working properly.</p>\n\n<p><a href="http://en.wikipedia.org/wiki/Integration_testing" rel="noreferrer">Integration Testing</a> is the phase of software testing in which individual software modules are combined and tested as a group. </p>\n\n<p><a href="http://en.wikipedia.org/wiki/Unit_testing" rel="noreferrer">Wikipedia</a> defines a unit as the smallest testable part of an application, which in Java/C# is a method. But in your example of Word and Sentence class I would probably just write the tests for sentence since I would likely find it overkill to use a <a href="http://en.wikipedia.org/wiki/Mock_object" rel="noreferrer">mock</a> word class in order to test the sentence class. So sentence would be my unit and word is an implementation detail of that unit.</p>\n'}, {'answer_id': 10924, 'author': 'CVertex', 'author_id': 209, 'author_profile': 'https://Stackoverflow.com/users/209', 'pm_score': 2, 'selected': False, 'text': '<p>I call unit tests those tests that white box test a class. Any dependencies that class requires is replaced with fake ones (mocks).</p>\n\n<p>Integration tests are those tests where multiple classes and their interactions are tested at the same time. Only some dependencies in these cases are faked/mocked.</p>\n\n<p>I wouldn\'t call Controller\'s integration tests unless one of their dependencies is a real one (i.e. not faked) (e.g. IFormsAuthentication).</p>\n\n<p>Separating the two types of tests is useful for testing the system at different levels. Also, integration tests tend to be long lived, and unit tests are supposed to be quick. The execution speed distinction means they\'re executed differently. In our dev processes, unit tests are run at check-in (which is fine cos they\'re super quick), and integration tests are run once/twice per day. I try and run integration tests as often as possible, but usually hitting the database/writing to files/making rpc\'s/etc slows.</p>\n\n<p>That raises another important point, unit tests should avoid hitting IO (e.g. disk, network, db). Otherwise they slow down alot. It takes a bit of effort to design these IO dependencies out - i can\'t admit I\'ve been faithful to the "unit tests must be fast" rule, but if you are, the benefits on a much larger system become apparent very quickly.</p>\n'}, {'answer_id': 38328, 'author': 'Larry Foulkrod', 'author_id': 1642688, 'author_profile': 'https://Stackoverflow.com/users/1642688', 'pm_score': 6, 'selected': False, 'text': "<p>When I write unit tests I limit the scope of the code being tested to the class I am currently writing by mocking dependencies. If I am writing a Sentence class, and Sentence has a dependency on Word, I will use a mock Word. By mocking Word I can focus only on its interface and test the various behaviors of my Sentence class as it interacts with Word's interface. This way I am only testing the behavior and implementation of Sentence and not at the same time testing the implementation of Word.</p>\n\n<p>Once I've written the unit tests to ensure Sentence behaves correctly when it interacts with Word based on Word's interface, then I write the integration test to make sure that my assumptions about the interactions were correct. For this I supply the actual objects and write a test that exercises a feature that will end up using both Sentence and Word.</p>\n"}, {'answer_id': 132341, 'author': 'Pavel Feldman', 'author_id': 5507, 'author_profile': 'https://Stackoverflow.com/users/5507', 'pm_score': 1, 'selected': False, 'text': '<blockquote>\n  <p>Have these tests essentially become integration tests because they now test the integration of these 2 classes? Or is it just a unit test that spans 2 classes?</p>\n</blockquote>\n\n<p>I think Yes and Yes. Your unit test that spans 2 classes became an integration test. </p>\n\n<p>You could avoid it by testing Sentence class with mock implementation - MockWord class, which is important when those parts of system are large enough to be implemented by different developers. In that case Word is unit tested alone, Sentence is unit tested with help of MockWord, and then Sentence is integration-tested with Word.</p>\n\n<p>Exaple of real difference can be following\n1) Array of 1,000,000 elements is easily unit tested and works fine.\n2) BubbleSort is easily unit tested on mock array of 10 elements and also works fine\n3) Integration testing shows that something is not so fine.</p>\n\n<p>If these parts are developed by single person, most likely problem will be found while unit testing BubbleSoft just because developer already has real array and he does not need mock implementation.</p>\n'}, {'answer_id': 1223466, 'author': 'Robert Koritnik', 'author_id': 75642, 'author_profile': 'https://Stackoverflow.com/users/75642', 'pm_score': 5, 'selected': False, 'text': "<p><strong>Unit tests use mocks</strong></p>\n\n<p>The thing you're talking about are integration tests that actually test the whole integration of your system. But when you do unit testing you should actually test each unit separately. Everything else should be mocked. So in your case of <code>Sentence</code> class, if it uses <code>Word</code> class, then your <code>Word</code> class should be mocked. This way, you'll only test your <code>Sentence</code> class functionality.</p>\n"}, {'answer_id': 7876055, 'author': 'Arialdo Martini', 'author_id': 202443, 'author_profile': 'https://Stackoverflow.com/users/202443', 'pm_score': 8, 'selected': False, 'text': '<p>The key difference, to me, is that <strong>integration tests</strong> reveal if a feature is working or is broken, since they stress the code in a scenario close to reality. They invoke one or more software methods or features and test if they act as expected.</p>\n\n<p>On the opposite, a <strong>Unit test</strong> testing a single method relies on the (often wrong) assumption that the rest of the software is correctly working, because it explicitly mocks every dependency.</p>\n\n<p>Hence, when a unit test for a method implementing some feature is green, it does <b>not</b> mean the feature is working.</p>\n\n<p>Say you have a method somewhere like this:</p>\n\n<pre><code>public SomeResults DoSomething(someInput) {\n  var someResult = [Do your job with someInput];\n  Log.TrackTheFactYouDidYourJob();\n  return someResults;\n}\n</code></pre>\n\n<p><code>DoSomething</code> is very important to your customer: it\'s a feature, the only thing that matters. That\'s why you usually write a Cucumber specification asserting it: you wish to <i>verify</i> and <i>communicate</i> the feature is working or not.</p>\n\n<pre><code>Feature: To be able to do something\n  In order to do something\n  As someone\n  I want the system to do this thing\n\nScenario: A sample one\n  Given this situation\n  When I do something\n  Then what I get is what I was expecting for\n</code></pre>\n\n<p>No doubt: if the test passes, you can assert you are delivering a working feature. This is what you can call <b>Business Value</b>.</p>\n\n<p>If you want to write a unit test for <code>DoSomething</code> you should pretend (using some mocks) that the rest of the classes and methods are working (that is: that, all dependencies the method is using are correctly working) and assert your method is working.</p>\n\n<p>In practice, you do something like:</p>\n\n<pre><code>public SomeResults DoSomething(someInput) {\n  var someResult = [Do your job with someInput];\n  FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log\n  return someResults;\n}\n</code></pre>\n\n<p>You can do this with Dependency Injection, or some Factory Method or any Mock Framework or just extending the class under test.</p>\n\n<p>Suppose there\'s a bug in <code>Log.DoSomething()</code>.\nFortunately, the Gherkin spec will find it and your end-to-end tests will fail.</p>\n\n<p>The feature won\'t work, because <code>Log</code> is broken, not because <code>[Do your job with someInput]</code> is not doing its job. And, by the way, <code>[Do your job with someInput]</code> is the sole responsibility for that method.</p>\n\n<p>Also, suppose <code>Log</code> is used in 100 other features, in 100 other methods of 100 other classes.</p>\n\n<p>Yep, 100 features will fail. But, fortunately, 100 end-to-end tests are failing as well and revealing the problem. And, yes: <b>they are telling the truth</b>.</p>\n\n<p>It\'s very useful information: I know I have a broken product. It\'s also very confusing information: it tells me nothing about where the problem is. It communicates me the symptom, not the root cause.</p>\n\n<p>Yet, <code>DoSomething</code>\'s unit test is green, because it\'s using a fake <code>Log</code>, built to never break. And, yes: <b>it\'s clearly lying</b>. It\'s communicating a broken feature is working. How can it be useful?</p>\n\n<p>(If <code>DoSomething()</code>\'s unit test fails, be sure: <code>[Do your job with someInput]</code> has some bugs.)</p>\n\n<p>Suppose this is a system with a broken class:\n<img src="https://i.stack.imgur.com/611ZY.jpg" alt="A system with a broken class"></p>\n\n<p>A single bug will break several features, and several integration tests will fail.</p>\n\n<p><img src="https://i.stack.imgur.com/rKhSr.jpg" alt="A single bug will break several features, and several integration tests will fail"></p>\n\n<p>On the other hand, the same bug will break just one unit test.</p>\n\n<p><img src="https://i.stack.imgur.com/M64Vb.jpg" alt="The same bug will break just one unit test"></p>\n\n<p>Now, compare the two scenarios.</p>\n\n<p>The same bug will break just one unit test.</p>\n\n<ul>\n<li>All your features using the broken <code>Log</code> are red</li>\n<li>All your unit tests are green, only the unit test for <code>Log</code> is red</li>\n</ul>\n\n<p>Actually, unit tests for all modules using a broken feature are green because, by using mocks, they removed dependencies. In other words, they run in an ideal, completely fictional world. And this is the only way to isolate bugs and seek them. Unit testing means mocking. If you aren\'t mocking, you aren\'t unit testing.</p>\n\n<h2>The difference</h2>\n\n<p>Integration tests tell <b>what</b>\'s not working. But they are of no use in <b>guessing where</b> the problem could be.</p>\n\n<p>Unit tests are the sole tests that tell you <b>where</b> exactly the bug is. To draw this information, they must run the method in a mocked environment, where all other dependencies are supposed to correctly work.</p>\n\n<p>That\'s why I think that your sentence "Or is it just a unit test that spans 2 classes" is somehow displaced. A unit test should never span 2 classes.</p>\n\n<p>This reply is basically a summary of what I wrote here: <a href="http://arialdomartini.wordpress.com/2011/10/21/unit-tests-lie-thats-why-i-love-them/" rel="noreferrer">Unit tests lie, that\'s why I love them</a>.</p>\n'}, {'answer_id': 11476650, 'author': 'Pascal', 'author_id': 401643, 'author_profile': 'https://Stackoverflow.com/users/401643', 'pm_score': 2, 'selected': False, 'text': '<p>Integration tests: Database persistence is tested.<br>\nUnit tests: Database access is mocked. Code methods are tested.</p>\n'}, {'answer_id': 17767843, 'author': 'David Sackstein', 'author_id': 2603228, 'author_profile': 'https://Stackoverflow.com/users/2603228', 'pm_score': 3, 'selected': False, 'text': '<p>In my opinion the answer is "Why does it matter?"</p>\n\n<p>Is it because unit tests are something you do and integration tests are something you don\'t? Or vice versa? Of course not, you should try to do both.</p>\n\n<p>Is it because unit tests need to be Fast, Isolated, Repeatable, Self-Validating and Timely and integration tests should not? Of course not, all tests should be these.</p>\n\n<p>It is because you use mocks in unit tests but you don\'t use them in integration tests? Of course not. This would imply that if I have a useful integration test I am not allowed to add a mock for some part, fear I would have to rename my test to "unit test" or hand it over to another programmer to work on.</p>\n\n<p>Is it because unit tests test one unit and integration tests test a number of units? Of course not. Of what practical importance is that? The theoretical discussion on the scope of tests breaks down in practice anyway because the term "unit" is entirely context dependent. At the class level, a unit might be a method. At an assembly level, a unit might be a class, and at the service level, a unit might be a component.\nAnd even classes use other classes, so which is the unit?</p>\n\n<p>It is of no importance.</p>\n\n<p>Testing is important, F.I.R.S.T is important, splitting hairs about definitions is a waste of time which only confuses newcomers to testing.</p>\n'}, {'answer_id': 18725056, 'author': 'Paulo Merson', 'author_id': 317522, 'author_profile': 'https://Stackoverflow.com/users/317522', 'pm_score': 1, 'selected': False, 'text': "<p>In addition, it's important to remember that both unit tests and integration tests can be automated and written using, for example, JUnit. \nIn JUnit integration tests, one can use the <code>org.junit.Assume</code> class to test the availability of environment elements (e.g., database connection) or other conditions. </p>\n"}, {'answer_id': 25976990, 'author': 'Lutz Prechelt', 'author_id': 2810305, 'author_profile': 'https://Stackoverflow.com/users/2810305', 'pm_score': 3, 'selected': False, 'text': "<h1>The nature of your tests</h1>\n\n<p>A <strong>unit test</strong> of module X is a test that expects (and checks for) problems only in module X.</p>\n\n<p>An <strong>integration test</strong> of many modules is a test that expects problems that arise from the cooperation <em>between</em> the modules so that these problems would be difficult to find using unit tests alone.</p>\n\n<p>Think of the nature of your tests in the following terms:</p>\n\n<ul>\n<li><strong>Risk reduction</strong>: That's what tests are for. Only a <em>combination of unit tests and integration tests</em> can give you full risk reduction, because on the one hand unit tests can inherently not test the proper interaction between modules and on the other hand integration tests can exercise the functionality of a non-trivial module only to a small degree.</li>\n<li><strong>Test writing effort</strong>: Integration tests can save effort because you may then not need to write stubs/fakes/mocks. But unit tests can save effort, too, when implementing (and maintaining!) those stubs/fakes/mocks happens to be easier than configuring the test setup without them.</li>\n<li><strong>Test execution delay</strong>: Integration tests involving heavyweight operations (such as access to external systems like DBs or remote servers) tend to be slow(er). This means unit tests can be executed far more frequently, which reduces debugging effort if anything fails, because you have a better idea what you have changed in the meantime. This becomes particularly important if you use test-driven development (TDD).</li>\n<li><strong>Debugging effort</strong>: If an integration test fails, but none of the unit tests does, this can be very inconvenient, because there is so much code involved that <em>may</em> contain the problem. This is not a big problem if you have previously changed only a few lines -- but as integration tests run slowly, you perhaps did <em>not</em> run them in such short intervals...</li>\n</ul>\n\n<p>Remember that an integration test may still stub/fake/mock away <em>some</em> of its dependencies.\nThis provides plenty of middle ground between unit tests and system tests (the most comprehensive integration tests, testing all of the system).</p>\n\n<h2>Pragmatic approach to using both</h2>\n\n<p>So a pragmatic approach would be: Flexibly rely on integration tests as much as you sensibly can and use unit tests where this would be too risky or inconvenient.\nThis manner of thinking may be more useful than some dogmatic discrimination of unit tests and integration tests.</p>\n"}, {'answer_id': 40986071, 'author': 'BenKoshy', 'author_id': 4880924, 'author_profile': 'https://Stackoverflow.com/users/4880924', 'pm_score': 2, 'selected': False, 'text': "<h2>Simple Explanation with Analogies</h2>\n\n<p>The above examples do very well and I needn't repeat them. So I'll focus on using examples to help you understand. </p>\n\n<h3>Integration Tests</h3>\n\n<p>Integration tests check if everything is working together. Imagine a series of cogs working together in a watch. An integration test would be: is the watch telling the correct time? Is it still telling the correct time in 3 days?</p>\n\n<p>All it tells you is whether the overall piece is working. If it fails: it doesn’t tell you exactly where it is failing.</p>\n\n<h3>Unit Tests</h3>\n\n<p>These are really specific types of test. They tell you whether one specific thing is working or failing. The key to this type of test is that it tests only one specific thing while assuming that everything else is working just fine. That’s the key point. </p>\n\n<p><em>Example:</em>\nLet’s elaborate on this point using an example:</p>\n\n<ul>\n<li>Let’s take a car as an example. </li>\n<li><strong>Integration</strong> test for a car: e.g. does the car drive to Woop Woop and back? If it does this, you can safely say that a car is working from an overall view point. It is an integration test. If it fails you have no idea where it is actually failing: is it the radiator, transmission, engine, or carburettor? You have no idea. It could be anything.</li>\n<li><strong>Unit test</strong> for a car: Is the engine is working? This tests assumes that everything else in the car is working just fine. That way, if this particular unit test fails: you can be very confident that the problem lies in the engine – so you can quickly isolate and fix the problem.</li>\n</ul>\n\n<h3>Using Stubs</h3>\n\n<ul>\n<li><p>Suppose your car integration test fails. It doesn’t drive successfully to Echuca. Where is the problem?</p></li>\n<li><p>Now let us suppose that your engine uses a special fuel injection system and that this engine unit test has also failed. In other words, both the integration test and the engine unit test have failed. Where then is the problem? (Give yourself 10 seconds to get the answer.)</p></li>\n<li><p>Is the problem with the engine, or with the fuel injection system?</p></li>\n</ul>\n\n<p>You see the problem here? You don’t know what exactly is failing. If you use different external dependencies, then every single one of those 10 could have caused the problem – and you won’t know where to start. That’s why unit tests use stubs to assume that everything else is working just fine.</p>\n"}, {'answer_id': 53123030, 'author': 'StevePoling', 'author_id': 1839838, 'author_profile': 'https://Stackoverflow.com/users/1839838', 'pm_score': 0, 'selected': False, 'text': "<p>If you're a TDD purist, you write the tests before you write production code. Of course, the tests won't compile, so you first make the tests compile, then make the tests pass.</p>\n\n<p>You can do this with unit tests, but you can't with integration or acceptance tests. If you tried with an integration test, nothing would ever compile until you've finished!</p>\n"}, {'answer_id': 57283806, 'author': 'Michu93', 'author_id': 4952262, 'author_profile': 'https://Stackoverflow.com/users/4952262', 'pm_score': 5, 'selected': False, 'text': '<p>In unit test you test every part isolated:\n<a href="https://i.stack.imgur.com/bmhZg.jpg" rel="noreferrer"><img src="https://i.stack.imgur.com/bmhZg.jpg" alt="enter image description here"></a></p>\n\n<p>in integration test you test many modules of your system:</p>\n\n<p><a href="https://i.stack.imgur.com/v186T.jpg" rel="noreferrer"><img src="https://i.stack.imgur.com/v186T.jpg" alt="enter image description here"></a></p>\n\n<p>and this what happens when you only use unit tests (generally both windows are working, unfortunately not together):</p>\n\n<p><a href="https://i.stack.imgur.com/yHGn1.gif" rel="noreferrer"><img src="https://i.stack.imgur.com/yHGn1.gif" alt="enter image description here"></a></p>\n\n<p>Sources:\n<a href="https://dariuszwozniak.net/posts/kurs-tdd-2-testy-jednostkowe-a-testy-integracyjne/" rel="noreferrer">source1</a>\n<a href="http://softwaretestingfundamentals.com/integration-testing/" rel="noreferrer">source2</a></p>\n'}, {'answer_id': 74559852, 'author': 'John', 'author_id': 866333, 'author_profile': 'https://Stackoverflow.com/users/866333', 'pm_score': 0, 'selected': False, 'text': '<p>I get asked this a lot in interviews. Until now I\'d ramble on pretentiously about my expertise and pontificate about component and acceptance testing.</p>\n<p>For years I\'d understood <strong>only</strong> integration and unit tests. I could, but didn\'t always bother to, write unit tests as a solo developer honing my skills.</p>\n<h2>Unit tests</h2>\n<p>That is a crucial difference. Unit tests are easy to implement and execute, requiring, ideally, no dependencies. That is what mocks are for. It is often easier to <em>not</em> mock <em>everything</em>, particularly where you gain coverage of other functions you wrote. Easier, maybe, but that isn\'t the idea of unit testing.</p>\n<p>I\'ll reiterate, unit tests are meant to be easy to run and small. Their failure provides immediate insight into where a bug has been introduced.</p>\n<p>Here is the hierarchy of tests, from cheap and plentiful at the bottom to slow, expensive, and few, at the top:</p>\n<p><a href="https://i.stack.imgur.com/gFsdT.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/gFsdT.png" alt="hierarchy of test expense and breadth." /></a></p>\n<p>Several more layers can be conceptualised, but were omitted for clarity.</p>\n<h2>Integration tests</h2>\n<p>With integration tests you would consider bringing in serious external dependencies, such as VMs, virtual networks and appliances. Possibly you could use actual modems, routers, and firewalls where the expense was justified.</p>\n<p>These wouldn\'t be run locally but on a build server. A mixture of local Jenkins and cloud based CI providers fulfil this need.</p>\n<h2>Other test terminology</h2>\n<p>That is my understanding that has served me for several years in industry. We could talk about component tests, and get a definition, but if the definition isn\'t in common circulation then it loses value.</p>\n<p>Acceptance tests were what we would call business unit or customer requirements. These would lead the direction of everything and sit at the top of the pyramid (picture a dollar sign).</p>\n<p>E2E, or end to end testing was used synonymously with integration tests, but I noticed online it is placed above. I guess it could have more relevance to acceptance tests the integration tests, which would tend to be more detailed with less interest from stakeholders (though immense interest internally in the department).</p>\n'}]
['https://Stackoverflow.com/questions/10752', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/122/']