Can Fake It ('Til You Make It) TDD pattern exist without a Triangulation in Real?

I was thinking once I 'fake' my implementation to make a test pass, until what time I should leave this fake implementation without changing it with the REAL implementation.

If TDD is about RED-GREEN-REFACTORING; and if I get to GREEN by faking it,

• should I implement the obvious implementation right after?

• OR should I wait until a new test calls this faked implementation and fails because it does not behave in the way it 开发者_JS百科expected? (Which sounds like a triangulation according to me)

So my question is:

Can Fake It('Till You Make It!) test driven pattern exist without a (deliberat or indeliberate) triangulation?

Thanks!

You should wait (but not long!) for a new failing test. At the moment you've turned your test green with a fake, you've got exactly the knowledge you need: you know what you're trying to develop, you know that you have a little unit test coverage for it, and you know that it's easy to fake out that test. And you know you've faked it.

So this is the moment to figure out another test that the current fake won't pass. Bring your bar back to red - and now you've got another decision to make: fake it more or make it right? If it's easier to keep the fake going, fake it some more and iterate. But if it's easier, finally, to write the code you know you need: write it. You'll be writing it safely, with just enough test coverage to feel good about it. Perfect!

Been discussing similar things at work. My view is that a Unit Test is just that it tests a small unit where its dependencies are mocks or stubs so that you can plug in some givens in order to assert your expectations.

Of course this leads to when do I actually implement my interfaces and more importantly how do I know the damn thing works. This is where Integration Tests or BDD Tests come in. When I come to write a particular feature or story I try to flesh out a BDD test which flows through the system, these tests should use all the real implementations up to any external boundaries. I try to use the same IoC wire up in the tests as would be used in the real application. Once this test has been fleshed out and is red you can start diving down to your unit tests and wiring the thing together. When you are finished your BDD test should be passing.

The nice thing about the BDD tests is that you can change certain parts of the internal components but as long as you don't change your requirements the test remain mostly unchanged.

I have been playing around with StoryQ for BDD tests and find it easy to use.