design - Inside Out TDD and unit tests evolution -

i developing application using inside out tdd , here sequence of steps identified in process:

1. write test basic functionality of class a

2. create class , implement needed functionality

3. write test additional functionality

4. implement needed functionality in class a

5. notice class violates srp

6. extract classes b , c services class uses

now, of questions have on "extracting crossroad" are:

this assumes injecting dependencies b , c in class a. should use mocks b , c or real instances?

if should use real instances of b , c, our unit tests test more 1 unit , become more unit tests (integration or perhaps acceptance tests)?

also, if should switch of original unit tests (targeting a) test b , c functionality, i've noticed becomes quite hard write:

1. arrange part tests testing b , c, and
2. setting expectations b , c mocks in unit tests class a

since data communicated between , b/c become more granulated , difficult setup.

that's clear statement of code costs of splitting out class. also, srp easy over-apply (any procedure more 1 statement self-evidently doing more 1 thing, , 'responsibility' malleable term).

so i'll wait on refactoring longer on many others. still, come due eventually, so...

when real class hard set up, or has real-world side-effects (and 'too slow' in bucket, me), i'll mock out. when it's simple enough use class instead of mock, haven't noticed fragility, has answered worries.

lastly, argument they're no longer 'unit' tests, yet that's prone counterproductive hair-splitting. single method on class 'unit', shouldn't mock out other methods calls? never, in experience. unit testing in eyes should pragmatic first, , theoretical purity, @ best, lagging second or third.