What is the difference between integration and uni

Question

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.

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

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?

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?

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

Answer 1

using Single responsibility design, its black and white. More than 1 responsibility, its an integration test.

By the duck test (looks, quacks, waddles, its a duck), its just a unit test with more than 1 newed object in it.

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.

Answer 2

In unit test you test every part isolated:

in integration test you test many modules of your system:

and this what happens when you only use unit tests (generally both windows are working, unfortunately not together):

Sources: source1 source2

Answer 3

A little bit academic this question, isn't it? ;-) My point of view: For me an integration test is the test of the whole part, not if two parts out of ten are going together. Our integration test shows, if the master build (containing 40 projects) will succeed. For the projects we have tons of unit tests. The 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.

Answer 4

Integration tests: Database persistence is tested.
Unit tests: Database access is mocked. Code methods are tested.

Answer 5

Simple Explanation with Analogies

The above examples do very well and I needn't repeat them. So I'll focus on using examples to help you understand.

Integration Tests

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?

All it tells you is whether the overall piece is working. If it fails: it doesn’t tell you exactly where it is failing.

Unit Tests

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.

Example: Let’s elaborate on this point using an example:

• Let’s take a car as an example.
• Integration 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.
• Unit test 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.

Using Stubs

• Suppose your car integration test fails. It doesn’t drive successfully to Echuca. Where is the problem?

• 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.)

• Is the problem with the engine, or with the fuel injection system?

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.

Answer 6

Unit tests use mocks

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 Sentence class, if it uses Word class, then your Word class should be mocked. This way, you'll only test your Sentence class functionality.