When does a unit end and Integration begin

Question

In TDD you write the smallest unit of code to make your test pass.

For example if building a Stack object you will want to test the push and pop methods. That is pretty straightforward. Those are both small units that can be tested in isolation. No external dependencies. It is about that object and what it does.

This is not the world though. Most objects depend on a lot of other objects. Those object might be filled from a service call or DB queries.

I know that use of Mocks, Stubs and Fakes can help here but also have limitations and pitfalls such as mocking too much which essentially lets test pass no matter what.

There is also integration testing that can make sure databases and services are all still integrating as expected but this is a step above unit-tests from my understanding. From what I have gathered this could be in a dev environment over a local.

Overall it would seem the act of removing these dependencies would be more work than it is worth almost. Which could lead to over-engineered test-suites.

Edit (including title)

Rather then understanding what the smallest unit is (the method thanks Robert) It appear my question is more:

• Where does unit-testing end and integration begin?
• For example is an integration test written by the developer like a unit test and then ran on the local with a test suite?
• If that is the case then how can someone distinguish between a unit test and integration tests or should they?
• Should unit-test and integration testing all be running at the same time?

Answer 1

Where does unit-testing end and integration [testing] begin?

Integration testing begins when you allow the units (methods) to talk to each other through their natural dependencies, and not to stubs, mocks or fakes.

is an integration test written by the developer like a unit test and then ran on the local with a test suite?

It can be. It can also be a command line test, a batch file, or the actual application automated through some tool like Selenium.

If that is the case then how can someone distinguish between a unit test and integration tests or should they?

You distinguish between a unit test and integration test by observing whether mocks or real dependencies are being used in the test.

The distinction between a real database or service and a mocked one is an important one. Mocking only demonstrates that the method under test behaves as you expect it to in isolation. It might have significantly different behavior when executed within the context of its actual operating environment.

Should unit-test and integration testing all be running at the same time?

Test methods should always be written in such a way that each one can be executed independently of the others. Most test frameworks allow more than one test to be run concurrently.

Answer 2

I'll try and answer your bullet points.

•Where does unit-testing end and integration begin?

As soon as one starts development. Keep tests focused. Know when a unit test is a good choice versus an integration test. Try and isolate your business logic so that unit tests can be written easily with a minimum amount of mocking/faking/stubbing.

•For example is an integration test written by the developer like a unit test and then ran on the local with a test suite?

Yes, they can be run like unit tests. For integrations tests, you can run them locally pointing to your local environment or the lowest environment in your stack. Typically these would be done/run by the developer to ensure the code works with real data and real services.

•If that is the case then how can someone distinguish between a unit test and integration tests or should they?

Yes, one should distinguish. With most testing frameworks this is easy with additional testing attributes.

[Test]
[Category=Unit]

[Test]
[Category=Integration]

Your team would come up with the categories.

•Should unit-test and integration testing all be running at the same time?

No, unit tests are run during the build on the build machine and integration tests are run post deployment on an environment. If one categorizes each test, the test runner can be configured only to run a certain suite of tests.

If a unit test fails, the build should fail. If an integration test fails, there may be issues with the environment or code. One should not deploy the code to a higher environment until the issue is identified and resolved.

As mentioned earlier, integration tests can be triggered manually by the developer to verify code correctness with actual service calls, but for automated scenarios=> build=unit tests : deployment=integration tests