Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

Slothlike's avatar

Where did you learn testing?

I'm losing my mind.

I know I must learn to test. I've tried multiple times. Jeffery's videos are great, it looks so easy, like anyone can do it.

But when I go to do it I end up flustered, frustrated, distraught then drained. I've spent 3 days on a thing that should have taken 2 hours.

And now, desperate and despite all I've achieved, I'm beginning to think I shouldn't even be a programmer because of this one (very important) thing.

There has to be something fundamental I'm missing. Some important "step" everyone has taken that I stepped over by accident. Like when everyone started using Macs to write software, I missed that memo.

It can't be Laravel Docs + Laracasts. I've done this loop multiple times now, I consume the tutorial and read the docs, I build the thing then I get stuck on like 6 tests for the next 3 days.

Please, is there some resource somewhere that clicked for you?

0 likes
10 replies
LaryAI's avatar
Level 58

Testing can be a challenging topic to learn, but it's an essential skill for any programmer. Here are some resources that may help:

  1. PHPUnit documentation: PHPUnit is the most popular testing framework for PHP, and its documentation is an excellent resource for learning how to write tests. Start with the Getting Started guide and work your way through the documentation.

  2. Laracasts: Jeffrey Way has created several video series on testing with PHPUnit and Laravel. Start with the "Testing Jargon" series, which covers the basics of testing terminology, and then move on to the "Testing Laravel" series.

  3. "The Art of Unit Testing" by Roy Osherove: This book is a comprehensive guide to unit testing, and it covers everything from the basics to advanced topics like test-driven development and mocking.

  4. "Clean Code" by Robert C. Martin: This book isn't specifically about testing, but it covers many best practices for writing clean, maintainable code, which is essential for writing good tests.

  5. Practice, practice, practice: The best way to learn testing is to write tests. Start with small, simple tests and work your way up to more complex tests. Don't be afraid to make mistakes; that's how you learn.

Here's an example of a simple PHPUnit test:

<?php

use PHPUnit\Framework\TestCase;

class MyTest extends TestCase
{
    public function testAddition()
    {
        $result = 2 + 2;
        $this->assertEquals(4, $result);
    }
}

This test checks that the result of adding 2 and 2 is equal to 4.

1 like
Slothlike's avatar

@LaryAI Yeah, OK. I'll re-read Clean Code. And, to be honest, I haven't spent enough time in PHPUnit docs, seems obvious now that you mention it. ChatGPT was a little more concerned with my mental health when I asked it the same thing. Thanks for giving it to me straight LaryAI.

kevinbui's avatar
kevinbui
Best Answer
Level 41

These are two resources that I found extremely valuable:

Btw, writing test cases are not that hard, I simply think in the AAA cycle (Arrange Act Assert).

2 likes
Slothlike's avatar

Thanks! Test Driven Laravel was actually on my radar at some point. I think I may have even purchased it. I honestly can't remember.

I got stuck writing tests for Builder classes and Actions. Then from the perspective of Jobs, Commands and Controllers. You say it's not that hard, and I believe it wouldn't be for you, but I keep tripping up and banging my head on the desk.

Maybe I'm just getting too old. Too old, too slow and too stubborn. Perhaps I should stick to writing only basic tests that assert only the most basic things. That way it "looks" like I'm testing.

I will revisit Test Driven Laravel, I appreciate you jogging my memory about that one. I'll check out Build a Forum too, it's one I started before but must have stopped to do my day job. 20 hours is a lot.

jlrdw's avatar

@Slothlike one testing video covers testing and looking for places to refactor. I don't remember the video.

But I mainly test looking for areas to refactor.

A test to see if something works to me is redundant, if you follow laravel conventions most anything you test will work simply because the framework is tested.

I have seen people test if a login works. I don't even see the need.

Many times I have seen questions where the actual code works but a test fails???

So does that mean you need a test to test the test?

Just my thoughts on testing.

2 likes
automica's avatar

To get real value out of your testing, you should approach the test as a means to write new code, as opposed to writing the code first and the. Writing the test after.

You should set up your test by defining the inputs you plan to pass into the method you are testing, and then define what you expect to happen when you call the new method you are writing.

Then run this test and it should always fail.

Once it fails you can then write the code and rerun the test as many times as it takes to eventually pass.

At this point you can modify the test or write a different more detailed test, run the test and it’ll fail, then write the code to make the test pass.

Doing it this way gives you confidence that your code is always working before you refactor.

In the context of your login form, having a test that proves your login form works will give you confidence that a user will always be able to login. You might also have a test for user registration for the same benefit. For an e-commerce site, if you inadvertently broke the registration form, you’d block all new customers from being able to purchase from your site. This would mean that test would be an essential part of your test coverage.

If you have a test that fails but the code passes by hand, then you need to investigate as your test and hand test aren’t testing with the same parameters.

For reliable tests, you should work from a clean database and then use factories to create the raw data you are testing against. You shouldn’t use a copy of the live data as it won’t be in a known state.

Eg for user registration, start with no users. Run a test that registers a new user and then use an assertion to check the data in the database matches the details of the new user you have registered. . Have a google for test driven development and you’ll find plenty of examples.

Once get your head around writing tests before you write your code, you’ll also find you write smaller more succinct methods, and have more confidence when you want to refactor

1 like
Slothlike's avatar

@automica Thanks. I'm taking this in. When I started the project TDD was what I set out to do. But then... I was getting into the weeds of something. I started using Actions to solve something and eventually found myself needing the Builder pattern, using more levels of abstraction than I ever had before. A few days later I was like oh, wait. I forgot I was doing TDD. Then I had to write tests. Perhaps if I'd just stuck with TDD I would have discovered I didn't even need Actions, Builders, Services, Repositories, DTO's and everything else I ended up using.

Slothlike's avatar

I give up. It's been another day of reading, listening and testing and another day of getting nowhere.

I mean, I know how to write the code. I just lack the understanding of which tests to write and what to put in them to get me where it needs to go when doing TDD.

test_it_selects_a_random_agent_when_one_is_not_specified_on_a_new_client

It's infuriating. I'm just going to write the code so I feel like I've accomplished something.

automica's avatar

@Slothlike your code should be answering a question. Your test is that question.

test name to describe what it does: (you can remove the test prefix if you add @test to the docblock above your test).

  • test_it_selects_a_random_agent_when_one_is_not_specified_on_a_new_client

could be

  • aNewClientReturnsARandomAgentWhenOneIsNotSpecified.

So you have a method that accepts an input, but in this test, you are passing an empty value. The value out would be random, and so you could use assertContains

assertContains(mixed $value, array $array, string $message = ''])

specifying the possible values your method returns.

another test would be:

  • aNewClientReturnsXWhenPassingInY

if you are testing a wide range of inputs and outputs you can use a data provider which DRYs up your test https://blog.martinhujer.cz/how-to-use-data-providers-in-phpunit/

Remember, without your test you can't guarantee your code works. Without a passing test suite any new code could break your existing methods and you'd never know.

1 like

Please or to participate in this conversation.