The 'Testing by Teaching' Challenge for Laravel

Question: Have you ever wondered why ExampleTest.php is named that way?

Think about it. It's a perfectly valid test for the existing front page route. It's simple, but correct. It's not an "example". It's real. You could start your testing suite with it.

Question: Have you ever wondered why we check our setup by opening the browser and typing in a url, instead of typing "phpunit" from the commandline?

In fairness, we are thinking more about our system than the code when we do that, but are there really that many things we might miss if we run a basic functional test to verify our initial config?

Question: Is RAD the antithesis of TDD?

This is the question I've been wrestling with for a while now, as I try to improve my methodology and create solid, dependable software - quickly enough to keep the project manager or client happy. I love Laravel precisely because it can get you through the mundane tasks quickly and have your basic site up and running in a weekend - but at what cost?

Why are my controllers still so fat? Why don't I have any coverage for anything that touches a database?

Why am I still doing TDR - "Test Driven Refactoring" - as I cut, cut, cut my controller functions and paste the code into a dozen little "helper" libraries and then add tests the best I can, knowing that once again I'm doing it wrong. Wondering how to get it right next time, while I type `Route::resource()` and copy/paste a new controller class and head right back down the road I just came from.

This is why when Taylor came out with his Basic Task List tutorial and Intermediate Task List tutorial, I was probably the only person who wasn't gushing about it. Yes, they are helpful, and nicely written. But they seemed to me to be a lot like the 500 "Getting Started with Laravel" tuts the internet already has.

Where are the tests?

"Oh, this is just a basic example," answers Hypothetical Answerer. Yes, but - you showed everything else. You showed migrations, and models, and routes, and views, and validation...Are tests not a part of a complete application?

"Oh, but this is so simple, there's no need for tests". I think we all know one of the biggest benefits of testing comes when our "simple" app starts to grow.

"Oh, I just wanted to get this out quickly. I didn't want to spend time..."

Urp.

Okay, point made. I've won. Let's move on to something practical. What are we going to do about this state of affairs?

I think this part is easy. We love Laravel because it is truly ground-breaking, not so importantly with its design patterns and internals, but its ability to help us get our work done quickly with quality because it looks at the problems we face every day in our work and addresses them with utility. Authentication, Cashier, Forge, Spark... See what is needed, and make it once for everyone to use. Let's tackle testing the same way.

Let's make Laravel be known for its Test Driven philosophy.

This is the challenge I want to throw out to the Laravel Community. I want each of us to go back to Taylor's new Basic Task List tutorial and build it. Only, stay as completely TDD as you can. Write an functional test for your route, then write the route. Then watch it bork because you don't have a controller. Or whatever. Build using the design patterns and techniques you prefer, but with tests from the beginning.

It's going to be slow. It's going to be awkward. It will remind you of the time in high school when you drove all the way home across your small, Midwestern town at 3am - in reverse. (Alright...we'll skip that story for now.)

Here's the second part of the Challenge. Write down what is slow and awkward. Anything that made you lose time or break your rhythm. Then let's fix those.

Tests run too slowly? Perhaps the TestGenerator could use a phpunit group annotation option when you create it. Too much commandline typing to set things up? Maybe "include test stub" can be an added option on generators. Whatever we need, let's discuss it.

Then let's make it.

Then let's teach it.