Worry not, my fellow aspiring devs; TDL is not yet another language concept, tool or package manager you must know waiting to roadblock you on your journey.
I'm already sensing there are enough of those already.
No, TDL, which I have decided Stands for Test Driven Learning, is just an on-the-fly made acronym to describe what I've so far discovered is my less-than-orthodox introduction to the Laravel framework.
As you might imagine, it means diving straight in there with those pesky tests.
As in writing a test to check my route loads ok before I know how to structure a route - that loads.
public function test_contacts_loads_ok(): void
{
$this
->get('contacts')
->assertOk()
->assertViewIs('contacts.index')
->assertViewHas(['contacts']);
}
As in writing a test to check I can push content to a database before I functionally even know how to access that database let alone provide it with content.
public function test_can_store_contact(): void
{
$this
->post('contacts/store', [
'name' => fake()->name(),
'email' => fake()->email(),
'country' => 'uk'
])
->assertSessionHasNoErrors()
->assertRedirect('contacts');
$this
->assertDatabaseCount(Contact::class, 1)
->assertDatabaseHas('contacts', ['country' => 'uk']);
}
And I can tell you it's been blast... 🚀
Also, it's not like I didn't cover the foundational concepts of Laravel - you know, the normal stuff we newbies are meant to be learning - just after we set up the tests.
My mentor, David Carr, (yes, I'm that lucky), being the testing enthusiast he is saw it as a benefit to start from this point and who am I to argue?
In fact by the time we got to the point when we were creating the test to edit and update a database record I was anticipating many of the steps I needed to take in advance based on how much I had learned not just from testing but from all the other aspects of creating a mini CRUD contacts application.
public function test_can_load_edit_page(): void
{
$contact = Contact::factory()->create();
$this
->get("contacts/$contact->id/edit")
->assertOk()
->assertViewIs('contacts.edit');
}
Not only has my Test Driven Learning experience introduced me to concepts of testing and debugging problems as I go, but it's also been really useful in terms of thinking what is the next logical step I need to complete.
And what's more. This testing game is starting to feel positively...
Easy! ✅ ✅ ✅
No excuses for not testing!
When I learned about the reality of finding an employer that is pro-testing I was a little surprised to hear testing is not always common practice. Not every dev studio is pro testing, and not every product owner thinks it's beneficial.
Some think testing is a waste of time, and some even tell their clients they test and sell it as an extra service. 😳
So, Like anyone functioning on the peak of Mount Stupid on the Dunning Kruger curve, I took what little knowledge I had and asked a question of an actual professional developer, when she told me she had not tested in her previous role,
"soooo why not just write tests anyway?"
Well, it turns out the implementation of testing is not that simple... not by a long shot.
For a start...
A product ideally needs to be set up from the early stages to be testable.
Perhaps this is difficult because controller methods may not follow SOLID principles and simply have too much logic to make testing straightforward.
An existing system likely also lacks the factories, seeders and test cases all necessary to make a realistic project testable in any kind of beneficial way.
Also in real life, existing projects have users, roles and even tenants which all play a role in being roadblocks to happy path testing.
So, getting that project into a testable state can take a on full week.
"So what"
Well a big question here is who is paying for that week?
And if you can jump those hurdles...
There is the small matter that if your development manager does not want you writing tests then you should not be writing tests.
Because there is that little matter of wanting to continue to be paid each month!
What next?
When starting a new project I will no doubt dive in with my testing principles. It's been fascinating to learn about the implementation of tests and why they are or are not found in any future projects I may be working on.
As an aspiring developer, I'm choosing to embrace testing where possible.