Fake it till you make it

Imagine a situation where you've decided to write a service that will create something (a product, for example). As is customary, the first thing you do is describe your expectation in an executable form (i.e. a test). Now, how would you describe that expectation?

You expect that a service which does not exist yet will do some work for the calling client. So the calling client (i.e. your expectation, your test) is the first customer of your as of yet non existent service. This customer of yours needs to express their expectation.

Sidebar: (sounds like I'm beating around the bush, but bear with me; we're slowly circling around a very important topic).

Back to the issue: how will the customer express their expectation, in an executable form, of a service that does not exist yet?

Kent Beck to the rescue: fake it till you make it!

The only way at that point in time that the customer (i.e. an executable test) can express their expectation is by fabricating a value (or some values). In other words, you hard-code expected value(s) in your test. You fake it.

You fake it in such a way to set it up for a fall. Why would you be so mean? Because it is super important to start your work with a broken system. TDD is based on always starting with a broken system.

So you run your test and watch it fail. Now you roll up your sleeves & fix it.

How do you fix it? By defining an end-point of your 'create 'product' service. You then teach your test to send a request to that end point.

What happens next? The end point receives the request, does some work, and --wait for it-- returns VALUE!

Now imagine if instead of returning some value(s), the endpoint returned VOID. How would your test feel? It would feel deflated, cheated. Your test would have no idea whether the endpoint actually did anything or not.

Furthermore, you may get worried if the endpoint did something unsavoury. Maybe after receiving your request the endpoint didn't do anything (what a waste), or worse yet, it did something that may cause all kinds of issues & calamities. You have no way of knowing.

Returning VOID is always bad, and is to be avoided (no pun intended). We should rely on clearly defined values in any of our engineering endeavours, no matter how tiny & insignificant they may feel.