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
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
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?