This article is about my experiences with TDD and a guideline I created for myself. It's my personal path from fearing writing tests to writing every feature using TDD.

What This Document Does Not Cover:

• The definition of TDD
• Types of tests
• Tools for writing tests
• Mocking, faking, etc. (to be discussed in Part 2)
• Third parties or other services being used in the service you want to test which needs to be mocked.

I had several questions at first. I still do, but they are not stopping me now. I couldn’t even write a single word.

Where should I start? What should I write when a test file is in front of me, waiting for me to type my code?

Which type of tests should I use?

How should I write the scenarios?

How can I predict how I am going to write the feature?

Seeking Inspiration from Examples

I tried to see as many samples as I could to form an initial picture in my mind about tests.

Writing Scenarios

Cost (which includes time) is one of the most important factors while writing code. That is one of the reasons we write tests. But "you have to choose your battles" instead of battling with everything. So, you must make an equilibrium between time and quality by choosing a suitable test type.

At this point, I didn’t know whether to choose Unit Tests or Feature Tests. A Feature Test, for example, for creating a user is a single path starting from a route (localhost:8000/user/create) to the logic until the user is being created successfully or not.

What I am dealing with mostly are CRUDs. Using TDD for most of the CRUD codes needs Feature Test.
Drafting Test Scenarios
You are facing a new task. You may have no idea how you want to write the code. Start with what is almost obvious: The Feature. Creating a user, updating a price, deleting an order, getting a list of foods.

Write what you expect:

It can create a user.
It can update the price.
It can delete an order.
It can get a list of foods.
They may also fail too, right? Look for the failing conditions.

It cannot create a user with an existing phone number.
It cannot update the price with an invalid price format.
...
Voila! You have your scenarios. For the format, check the team and framework conventions.

Write the scenarios in your test file as methods with no content.

laravel example:

Detailing Your Tests

Now that you have your scenarios, it is time to write the test contents. Slow down here a little bit if you have a challenge like I did. You are writing a path (Feature Test).

Write the beginning and ending points first. The beginning point is the route; the ending point is the response, whether it is an HTTP status code or content.
Well, you have come to the main part of the road.

Identifying Prerequisites

Now, you must see what the prerequisites are. It can be a pre-created user (for failing tests of creating a user, for updating a price or for deleting an order) or a pre-created product you want to update its price.

You successfully have failing tests! It is time to pass these tests. You may face the need for making changes that may affect your code; change the test first.

Keep this cycle:
Write the test that fails, write the code that passes the test.

That’s it! I would be happy to read your experiences too.