TDD Test Structure Question

Question

So say I'm doing TDD and I write a test like this:

public void testDeposit()
{
    Bank b = new Bank();
    b.deposit(100);
    AssertEquals(100, b.balance);
}

Then I go and make the test pass, move on to the next one. Say I do this for a few in a row and get deposits, withdrawals, and amortization all working.

Then say I want to write a test that tests someone creating an account and doing a combination of everything. Isn't this technically an integration test, not a unit test? If it is, does this fit into TDD, or is TDD supposed to only consist of unit tests.

Mainly I'm asking because, if this test breaks, most likely one of the other tests should break, and if they don't, I probably just haven't tested them with the right amount of scenarios. So should I have integration tests in the same domain as unit tests when it comes to TDD, or should these be written in another class/file somewhere else and run separately?

Answer 1

I think high level tests can certainly have a place as part of a TDD workflow. For example testing "outside in" can be a very effective way to define new features. Start with some UI level acceptance test for the new feature, write integration tests for the components which will need to exist to provide that feature, and write unit tests to drive the implementation of each component.

I think you should keep the distinction between your types of tests clear and not mix them together but it can make sense to include all of them as part of your TDD process.