DEV Community: Antonio Silva

Primeiro Livro Publicado

Antonio Silva — Wed, 15 Apr 2026 16:44:26 +0000

🚀 Publiquei meu primeiro livro na Amazon!

📘 PHP do Zero: Guia Completo para Iniciantes

Depois de muito trabalho, lancei um guia completo para quem quer aprender PHP do zero, com explicações claras e práticas.

Se você está começando na programação ou quer reforçar os fundamentos, esse livro é pra você.

🔗 https://www.amazon.com.br/dp/B0GX3BQPH5

Responsive Images in HTML

Antonio Silva — Sat, 15 Nov 2025 21:28:52 +0000

In a world where a large portion of traffic comes from mobile devices, making your images responsive is essential for delivering a great user experience. Poorly sized images can break layouts, waste bandwidth, and even harm your page performance.

In this post, you’ll learn what responsive images are, why they matter, and how to implement them in HTML using modern best practices.

What Are Responsive Images?

Responsive images are images that automatically adjust to the size of the screen or the element they’re placed in. This ensures that the image:

Doesn’t overflow the layout
Scales proportionally
Improves loading on different devices
Avoids unnecessary bandwidth usage

Basic Responsiveness with CSS

The most basic yet very effective way to make an image responsive is through CSS:

<img src="image.jpg" alt="Image description">

img {
    max-width: 100%;
    height: auto;
    display: block;
}

Why this works:

max-width: 100%
Tells the browser:
👉 “this image should never be wider than its container.”
height: auto
Keeps the aspect ratio intact.
display: block
Removes the small whitespace that images have by default (because they’re inline elements).

Result:
The image shrinks smoothly on small screens without distortion.

Smart Responsiveness with `srcset`

Now we use native HTML5 features. If you want to give the browser multiple resolution options and let it choose the best one, use srcset.

The browser will automatically choose the best image depending on:

screen width
pixel density
layout rules you define

<img 
    src="img-800.jpg"
    srcset="
        img-400.jpg 400w,
        img-800.jpg 800w,
        img-1600.jpg 1600w
    "
    sizes="(max-width: 600px) 400px,
           (max-width: 1200px) 800px,
           1600px"
    alt="Image description">

How the browser decides which file to load

It evaluates:

screen size
device pixel ratio (1x, 2x, 3x)
rules in sizes

Example:

Small phones → load img-400.jpg
Tablets/laptops → load img-800.jpg
Large monitors → load img-1600.jpg

Benefits:

faster loading
less bandwidth
better battery usage
improved SEO (Google Lighthouse loves this)

Using the `<picture>` Element (The Modern & Powerful Approach)

To deliver different images depending on the device (screen size, resolution, or format), HTML provides the <picture> element.

<picture>
    <source media="(max-width: 600px)" srcset="photo-mobile.jpg">
    <source media="(max-width: 1200px)" srcset="photo-tablet.jpg">
    <img src="photo-desktop.jpg" alt="Fully responsive photo">
</picture>

Explanation:

On screens up to 600px → loads photo-mobile.jpg
On screens up to 1200px → loads photo-tablet.jpg
Otherwise → loads photo-desktop.jpg

This boosts performance, as each device loads only what it needs.

When this is essential:

Vertical image on mobile.
Horizontal version on desktops.
Using modern formats with fallback.
Art direction (different compositions per device).

Difference Between `srcset` Using w and x

There are two ways to write responsive image sets.

A) Width-based (w) — Modern and recommended

<img src="img-800.jpg"
     srcset="img-400.jpg 400w, img-800.jpg 800w, img-1600.jpg 1600w"
     sizes="100vw"
     alt="">

The browser calculates the final display width.
Selects the most appropriate file.

B) Pixel-density-based (x)

<img src="img.jpg"
     srcset="img.jpg 1x, img@2x.jpg 2x, img@3x.jpg 3x"
     alt="">

Best for:

logos
icons
UI images

Example:

A 3x retina screen → loads img@3x.jpg.

Common Issues and How to Avoid Them

1. Image overflows outside the screen

Use:

img { max-width: 100%; height: auto; }

2. Image looks stretched

→ Remove fixed width or height in the HTML.

3. Images look blurry on mobile

→ Use srcset.

4. Image appears smaller than expected

→ Ensure the container doesn’t have a too-small max-width.

When to Use Each Technique

Situation	Best Technique
Only want the image to shrink on small screens	CSS `max-width: 100%`
Want performance and smaller downloads on mobile	`srcset + sizes`
Want completely different images per screen size	`<picture>`
Want WebP/AVIF with fallback	`<picture>`
Want high-resolution images for retina screens	`srcset 1x, 2x, 3x`

Responsive images are essential for building modern, fast, and adaptable websites. With a few lines of HTML and CSS, you ensure your images display properly on any device from smartphones to 4K screens.

If you want to go further, <picture>, srcset, and sizes offer fine-grained control over performance, quality, and compatibility.

How to create and publish your own packages on Packagist

Antonio Silva — Sat, 08 Nov 2025 20:48:08 +0000

What Is Packagist?

Packagist.org is the official package repository for Composer, PHP’s dependency manager. It’s where packages are published so anyone can install them easily using:

composer require yourusername/yourpackage

Requirements

Before you start, you’ll need:

A GitHub account
A Packagist.org account
PHP installed
Composer installed (composer --version to check)
Basic understanding of PHP namespaces and classes

Step 1 — Basic Package Structure

Create a folder for your project:

mkdir MyPackage
cd MyPackage

Inside it, create this structure:

MyPackage/
├── src/
│   └── Greeting.php
├── composer.json
└── README.md

Example of src/Greeting.php

<?php

namespace MyPackage;

class Greeting
{
    public static function hello($name)
    {
        return "Hello, {$name}!";
    }
}

Step 2 — Create the `composer.json` File

In the root directory, create a file named composer.json with this content:

{
    "name": "yourusername/my-package",
    "description": "A simple greeting package in PHP",
    "type": "library",
    "license": "MIT",
    "autoload": {
        "psr-4": {
            "MyPackage\\": "src/"
        }
    },
    "authors": [
        {
            "name": "Your Name",
            "email": "youremail@example.com"
        }
    ],
    "require": {}
}

⚠️ The "name" field must follow the pattern username/package, matching your GitHub username.

Step 3 — Test the Autoload Locally

Before publishing, test the autoload to make sure everything works.

Run:

composer install

Then create a test.php file:

<?php

require __DIR__ . '/vendor/autoload.php';

use MyPackage\Greeting;

echo Greeting::hello("MyPackage");

Run:

php test.php

Expected output:

Hello, MyPackage!

Step 4 — Push the Project to GitHub

1. Create a public repository on GitHub (e.g., my-package).

2. Initialize the local repository:

git init
git add .
git commit -m "First version of the package"
git branch -M main
git remote add origin https://github.com/yourusername/my-package.git
git push -u origin main

3. Create a version tag (Packagist uses tags to detect releases):

git tag v1.0.0
git push origin v1.0.0

Step 5 — Publish on Packagist

1. Go to https://packagist.org/packages/submit

2. Paste your GitHub repository URL, for example:

https://github.com/yourusername/my-package

3. Click Check, then Submit.

Done 🎉 — your package is now public on Packagist!

Step 6 — Enable Automatic Updates via GitHub Hook

After publishing, you can enable automatic updates:

Go to your package page on Packagist.
Click “Maintain”.
Under “GitHub Hook”, click “Connect” to allow Packagist to auto-update your package whenever you push changes to GitHub.

Step 7 — Using Your Package in Another Project

In any other PHP project, just run:

composer require yourusername/my-package

And use it like this:

use MyPackage\Greeting;

echo Greeting::hello("World");

Final Tips

Use semantic versioning (semver) (v1.0.0, v1.1.0, v2.0.0, etc.)
Keep a clear README.md explaining usage.
Add unit tests with PHPUnit.
Use GitHub Actions for automated testing.

Module 5: Advanced Topics and Best Practices

Antonio Silva — Sat, 01 Nov 2025 22:41:12 +0000

Congratulations on reaching the final module of our course! You've come a long way, from the initial setup of PHPUnit to mastering the use of Mocks and Stubs. Now it's time to refine your skills, ensure your tests are a sustainable asset for your project, and integrate this practice into your professional development workflow.

In this module, we will cover code coverage analysis, integration with CI/CD pipelines, and the best practices that separate a junior developer from a senior one when it comes to testing.

1. Code Coverage Analysis: What are your tests not seeing?

Writing tests is great, but how do you know if you're testing enough parts of your code? Code coverage is a metric that answers this question. It measures, as a percentage, how many lines or "branches" (such as if/else statements) of your production code were executed during your test suite.

Why is it important?

Identifies Untested Code: Code coverage is a fantastic tool for visualizing which parts of your application lack tests.
Increases Confidence: High code coverage gives the team more confidence to perform refactoring and add new features, knowing that there is a safety net to detect regressions.
Not a Silver Bullet: It's crucial to understand that 100% coverage doesn't mean 100% quality. It's possible to execute a line of code without actually testing its logic correctly (for example, without adequate assertions). Coverage is a guide, not a blind end goal.

How to Generate a Coverage Report:

To generate coverage reports, PHPUnit needs a code coverage driver such as Xdebug or PCOV. Xdebug is more common in development environments, while PCOV is lighter and faster, making it an excellent option for automation pipelines.

Once you have a driver installed and activated, you can generate an HTML report, which is very visual and easy to navigate.

1. Project structure

coverage/
├── src/
│   └── Calculator.php
├── tests/
│   └── CalculatorTest.php
├── composer.json
└── phpunit.xml

2. Source code – src/Calculator.php

<?php

namespace App;

class Calculator
{
    public function sum(int $a, int $b): int
    {
        return $a + $b;
    }

    public function subtract(int $a, int $b): int
    {
        return $a - $b;
    }

    public function divide(int $a, int $b): float
    {
        if ($b === 0) {
            throw new \InvalidArgumentException("Division by zero");
        }

        return $a / $b;
    }
}

3. Teste PHPUnit – tests/CalculatorTest.php

<?php

use PHPUnit\Framework\TestCase;
use App\Calculator;

class CalculatorTest extends TestCase
{
    public function testSum()
    {
        $calc = new Calculator();
        $this->assertEquals(5, $calc->sum(2, 3));
    }

    public function testSubtract()
    {
        $calc = new Calculator();
        $this->assertEquals(1, $calc->subtract(3, 2));
    }

    public function testDivide()
    {
        $calc = new Calculator();
        $this->assertEquals(2.5, $calc->divide(5, 2));
    }

    public function testDivideByZero()
    {
        $this->expectException(\InvalidArgumentException::class);

        $calc = new Calculator();
        $calc->divide(5, 0);
    }
}

4. PHPUnit configuration – phpunit.xml

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/12.0/phpunit.xsd"
         bootstrap="vendor/autoload.php"
         colors="true">

    <testsuites>
        <testsuite name="Testes da Calculadora">
            <directory>tests</directory>
        </testsuite>
    </testsuites>

    <source>
        <include>
            <directory>src</directory>
        </include>
    </source>

</phpunit>

The new <source> tag (in more recent versions of PHPUnit) or <coverage>/<filter> (in older versions) specifies that only the code within the src directory should be considered for coverage analysis.

5. Run PHPUnit with the coverage flag.

In the terminal, execute the following command:

vendor/bin/phpunit --coverage-html coverage-report

This command will run your tests and create a detailed HTML report in a new folder, coverage-report. Open the index.html file in that folder in your browser. You will see an overview of your project's coverage and can navigate through specific files and lines, seeing exactly what was and what was not executed.

2. Continuous Integration (CI/CD): Automating Your Safety Net

Continuous Integration (CI) is the practice of automatically integrating code changes from multiple contributors into a single software repository. A key part of CI is the automatic execution of tests with each new integration (for example, on every git push).

Why integrate tests into a CI/CD pipeline?

Fast Feedback: Developers know almost immediately if their change broke some part of the application.
Regression Prevention: Ensures that faulty code doesn’t reach the main branch of your project, let alone production.
Consistent Quality: Maintains a quality standard by ensuring all tests pass before any code merge.

Tools like GitHub Actions, GitLab CI/CD, and Jenkins make it easy to set up a pipeline that:

Checks out your code.
Installs dependencies with composer install.
Runs your test suite with ./vendor/bin/phpunit.
(Optional) Fails the build if any test fails.
(Optional) Publishes coverage reports for analysis.

Your PHPUnit test suite becomes the first automated line of defense for your project.

3. Refactoring for Testability

Sometimes, testing a class is difficult. This is usually not a problem with the testing tool itself, but rather a sign that the class design could be improved. Writing tests forces us to think about coupling and cohesion.

Principles for Testable Code:

Dependency Injection: Instead of creating dependencies inside a class (with the new operator), inject them through the constructor. This allows you to easily replace real dependencies with mocks or stubs in your tests. (We’ve done this in modules 3 and 4!)
Single Responsibility Principle (SRP): Classes that “do too many things” are hard to test. Break them down into smaller, more focused classes. If your class name contains the word “And”, it may be violating SRP (e.g., UserCreatorAndEmailSender).
Avoid Global State and Singletons: Functions and classes that rely on global state are a nightmare to test since one test’s result can affect another.
Program to an Interface, Not an Implementation: Depending on interfaces rather than concrete classes (as we did with Logger and Translator) makes your code more flexible and easier to mock in tests.

4. Testing Patterns and Antipatterns

Best Practices (Patterns):

One Test, One Logical Assertion: Ideally, each test method should verify one thing. There can be multiple physical asserts, but they should all check the same logical concept.
Arrange, Act, Assert (AAA): Structure your tests into three clear sections:
- Arrange: Prepare the environment, create objects and stubs.
- Act: Execute the method being tested.
- Assert: Verify that the result is as expected.
Descriptive Names: testSumShouldThrowExceptionWhenArgumentIsNotNumeric() is much better than testSum().
Fast Tests: Unit tests should be extremely fast. Avoid interacting with the file system, network, or database—use test doubles for that.

Mistakes to Avoid (Antipatterns):

Dependent Tests: A test that only passes if another test has run before it. Use setUp() and tearDown() to ensure isolation.
Slow Tests: Tests that take too long to run will eventually be ignored by the team.
Fragile Tests: Tests that break with any small refactor in production code. This often happens when you test implementation instead of behavior.
Testing Trivial Logic: Don’t waste time testing simple getters and setters that contain no logic. Focus on complex behavior.

Course Conclusion

You’ve reached the end of our PHPUnit journey! Now, you not only know how to write tests, but also why each technique matters. You’ve learned how to isolate your code, test complex interactions, measure your test effectiveness through coverage, and integrate everything into a professional workflow.

The next step is to apply this knowledge. Start small: pick a new feature in your project and write tests for it. Take an existing class without tests and try adding them. Constant practice is what will solidify your skills.

Automated tests are not a waste of time—they’re an investment in your software’s quality, maintainability, and longevity.

Welcome to the world of more reliable and professional software development!

Module 4: Uncovering Test Doubles (Mocks and Stubs)

Antonio Silva — Sat, 06 Sep 2025 23:22:54 +0000

Welcome to the module that will transform the way you write unit tests. Until now, we have tested classes that were largely independent. In the real world, however, classes collaborate with each other. A UserService class might need an EmailClient class to send emails, or a Logger to record activities.

How can we test the logic of the UserService without actually sending an email or writing to a log file every time the test runs? The answer lies in Test Doubles, a fundamental concept for test isolation.

1. What are Test Doubles?

A Test Double is a generic term for any object that pretends to be another object for testing purposes. Think of it like a movie stunt double: they step in to replace the main actor in specific situations, allowing the scene to be filmed safely and in a controlled manner.

In our case, we use doubles to replace the dependencies of the class we are testing (the "Unit Under Test"). This allows us to:

Isolate the Unit Under Test: We ensure our test fails only if there is a problem in the class we are testing, not in its dependencies.
Control the Environment: We can force dependencies to behave in specific ways (e.g., simulate a database connection failure) to test all paths of our code.
Speed Up Tests: Replacing a slow dependency (like a network call) with an in-memory double makes test execution orders of magnitude faster.

The two most common types of Test Doubles you will use with PHPUnit are Stubs and Mocks.

2. Stubs: Simulating Behavior (State Control)

A Stub is a double that provides "canned answers" to method calls made during the test. The main purpose of a stub is to ensure your unit under test receives the data it needs to do its job, allowing the test to continue.

When to use a Stub? When you need to simulate the state of a dependency.

Practical Example:

Imagine a WelcomeGenerator class that depends on a Translator to get the correct greeting.

// src/Translator.php
interface Translator
{
    public function getGreeting(): string;
}

// src/WelcomeGenerator.php
class WelcomeGenerator
{
    private $translator;

    public function __construct(Translator $translator)
    {
        $this->translator = $translator;
    }

    public function greet(string $name): string
    {
        $greeting = $this->translator->getGreeting();
        return "{$greeting}, {$name}!";
    }
}

To test the WelcomeGenerator, we don't want to depend on a real implementation of Translator. Instead, we create a stub.

// tests/WelcomeGeneratorTest.php
use PHPUnit\Framework\TestCase;

class WelcomeGeneratorTest extends TestCase
{
    public function testGreetingInEnglish()
    {
        // 1. Create a stub for the Translator interface
        $translatorStub = $this->createStub(Translator::class);

        // 2. Configure the stub: When the 'getGreeting' method is called,
        //    it should return the string 'Hello'.
        $translatorStub->method('getGreeting')->willReturn('Hello');

        // 3. Inject the stub into our class under test
        $generator = new WelcomeGenerator($translatorStub);

        // 4. Execute and assert
        $result = $generator->greet('John');
        $this->assertEquals('Hello, John!', $result);
    }
}

In this test, it doesn't matter how the translator works. We only care that it provides us with the string "Hello" so we can verify that the WelcomeGenerator concatenates it correctly with the name.

3. Mocks: Verifying Interactions (Behavior Verification)

A Mock is a "smarter" double. Like a stub, it can return values, but its main purpose is to verify that certain methods were called on the dependency. Mocks are used to test the interaction between objects.

When to use a Mock? When you need to verify that your class under test is correctly calling the methods of its dependencies.

Practical Example:

Let's imagine a UserRegistrar that, after saving a user, must notify a Logger service.

// src/Logger.php
interface Logger
{
    public function log(string $message): void;
}

// src/UserRegistrar.php
class UserRegistrar
{
    private $logger;

    public function __construct(Logger $logger)
    {
        $this->logger = $logger;
    }

    public function register(string $name)
    {
        // Logic to save the user to the database...
        echo "Saving user {$name}...\n";

        // Notify the logger
        $this->logger->log("User {$name} registered successfully.");
    }
}

The test needs to ensure that the log method of the Logger is called.

// tests/UserRegistrarTest.php
use PHPUnit\Framework\TestCase;

class UserRegistrarTest extends TestCase
{
    public function testShouldLogMessageOnRegister()
    {
        // 1. Create a mock for the Logger interface
        $loggerMock = $this->createMock(Logger::class);

        // 2. Set the expectation: We expect the 'log' method
        //    to be called EXACTLY ONCE.
        $loggerMock->expects($this->once())
                   ->method('log')
                   ->with($this->equalTo('User Alice registered successfully.'));

        // 3. Inject the mock into our class under test
        $registrar = new UserRegistrar($loggerMock);

        // 4. Execute the method
        $registrar->register('Alice');
    }
}

Analyzing the Mock:

createMock(): Creates the mock object.
expects($this->once()): This is the expectation. We are telling PHPUnit: "I expect that during the execution of this test, the following method will be called exactly one time." Other options include any(), never(), atLeastOnce().
method('log'): Specifies the method we are observing.
with(...): (Optional) Specifies the exact arguments with which we expect the method to be called.

If the log method is not called, or is called more than once, or is called with a different message, the test will fail, even if there is no explicit assert at the end. The expectation (expects) itself is an assertion.

4. Crucial Differences: Mocks vs. Stubs

Characteristic	Stub	Mock
Main Purpose	Provide canned answers (state)	Verify interactions (behavior)
Test Focus	On the final state of the object under test	On the communication between the test object and its dependency
Verification	The test makes assertions against the class under test	The test verifies that the mock was used as expected (`expects`)
Analogy	An actor with a fixed script	An actor being watched by a director who checks their actions

5. Other Doubles: Fakes and Spies

Although Mocks and Stubs are the most common, it's worth briefly knowing two other types:

Fakes: These are objects that have a working implementation, but it's much simpler than the production version. A classic example is an in-memory database that replaces a real connection to MySQL or PostgreSQL. It works, but it's simplified for testing purposes.
Spies: A spy is a double that "spies on" method calls without interfering with them (unless instructed to do so). After the code is executed, you can make assertions about how the spy was used. In PHPUnit, you can often achieve spy-like behavior by using a mock with flexible expectations.

Next Steps:

Mastering the use of Stubs and Mocks is a giant leap in your ability to write effective and truly "unit" tests. In the next and final module, we will bring together all the knowledge you've acquired and explore advanced topics like code coverage analysis, integrating your tests into a CI/CD workflow, and best practices to ensure your test suite is a valuable asset to your project.

Module 3: Deepening Your Testing Knowledge

Antonio Silva — Sat, 30 Aug 2025 18:38:05 +0000

Module 3: Deepening Your Testing Knowledge

You have now mastered the basics: you know how to set up PHPUnit, write test classes, and use the most important assertions. Now, let's deepen our knowledge with techniques that will make your tests more efficient, organized, and powerful. In this module, you will learn how to run the same test with multiple datasets, how to prepare the "stage" for your tests, and how to organize your test suite professionally.

1. Data Providers: Test More with Less Code

Imagine you need to test a sum function with various combinations of numbers: positive, negative, zeros, etc. You could write a test method for each combination, but that would lead to a lot of code duplication.

This is exactly the problem that Data Providers solve. A data provider is a public method in your test class that returns an array of arrays. Each of these inner arrays contains the arguments for one execution of your test method.

How It Works:

Create a test method that accepts arguments.
Create a public method that returns an array of arrays (or an Iterator object). This is your data provider.
Annotate the test method with the #[DataProvider('method')] tag.

Practical Example:

Let's test a simple Calculator class.

// src/Calculator.php
namespace App;

class Calculator
{
    public function sum(int $a, int $b): int
    {
        return $a + $b;
    }
}

Now, the test with a data provider:

// tests/CalculatorTest.php
use PHPUnit\Framework\Attributes\DataProvider;
use PHPUnit\Framework\TestCase;
use App\Example;

class CalculatorTest extends TestCase
{
    #[DataProvider('sumProvider')]
    public function testSumWithDifferentValues(int $a, int $b, int $expected)
    {
        $calculator = new Calculator();
        $result = $calculator->sum($a, $b);
        $this->assertEquals($expected, $result);
    }

    public static function sumProvider(): array
    {
        return [
            'Sum of two positives'      => [2, 3, 5],
            'Sum of positive with zero' => [5, 0, 5],
            'Sum of two negatives'      => [-2, -3, -5],
            'Sum of positive with negative' => [5, -3, 2],
        ];
    }
}

Analyzing the Example:

**use PHPUnit\Framework\Attributes\DataProvider;**: Imports the DataProvider attribute, which is a modern way (PHP 8+) of connecting a test method to a data provider.
#[DataProvider('sumProvider')]: This attribute is the central piece. It tells PHPUnit: "To run this test, first call the sumProvider() method to get a set of data. Then, execute this test method once for each data set it provides."
public function testSumWithDifferentValues(int $a, int $b, int $expected): This is the test method itself. The parameters $a, $b, and $expected will receive their values from the sumProvider.
he **sumProvider** method returns an array. Each item in this array is another array containing the data for one test run: [$a, $b, $expected].
$this->assertEquals($expected, $result);: This is the assertion (the check). It compares if the expected result ($expected) is equal to the actual result ($result). If they are equal, the test for that data set passes ✅. If not, it fails ❌.

When you run this test, PHPUnit will execute testSumWithDifferentValues four times, once for each dataset provided by sumProvider.

2. Fixtures and the Test Lifecycle: `setUp()` and `tearDown()`

In many tests, you need to perform some setup actions before running the test logic and some cleanup actions afterward. For example, you might need to create an object instance before each test or clear a log file after execution. This predefined environment and state is called a fixture.

PHPUnit provides two special methods to manage your test's lifecycle and ensure that each test runs in a clean, isolated environment:

setUp(): This method is executed before each test method (test*) in the class. It's the perfect place to instantiate objects or prepare the environment.
tearDown(): This method is executed after each test method. It's used to "clean up the mess," such as closing database connections or removing temporary files.

Practical Example:

Let's refactor our CalculatorTest to use setUp().

// tests/CalculatorTest.php
<?php

use PHPUnit\Framework\TestCase;
use App\Calculator;

class CalculatorTest extends TestCase
{
    private ?Calculator $calculator;

    protected function setUp(): void
    {
        // This line will run before EACH test in this class
        $this->calculator = new Calculator();
        echo "Running setUp()\n";
    }

    protected function tearDown(): void
    {
        // This line will run after EACH test in this class
        unset($this->calculator);
        echo "Running tearDown()\n";
    }

    public function testSimpleSum()
    {
        $result = $this->calculator->sum(1, 1);
        $this->assertEquals(2, $result);
    }

    public function testSumWithNegatives()
    {
        $result = $this->calculator->sum(-5, 2);
        $this->assertEquals(-3, $result);
    }
}

By using setUp(), we avoid writing $calculator = new Calculator(); in every test method, making our code cleaner (DRY principle - Don't Repeat Yourself) and ensuring that each test gets a fresh instance of the object. This prevents the result of one test from interfering with another.

3. Organizing Your Tests: The `phpunit.xml` File

As your project grows, running tests from the terminal by specifying the directory every time becomes repetitive. PHPUnit can be configured through an XML file, usually named phpunit.xml or phpunit.xml.dist, in the root of your project.

This file allows you to define default settings for your test suite, such as:

The directory where the tests are located.
The "bootstrap" file (a file that is executed before the tests begin, perfect for loading the Composer autoloader).
Colors in the terminal output.
And many other advanced options we'll see later, like filters and code coverage.

Creating a basic phpunit.xml:

Create the file phpunit.xml in your project's root directory.

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/10.0/phpunit.xsd"
         bootstrap="vendor/autoload.php"
         colors="true">

    <testsuites>
        <testsuite name="Unit">
            <directory suffix="Test.php">./tests</directory>
        </testsuite>
    </testsuites>

</phpunit>

Analyzing the File:

bootstrap="vendor/autoload.php": Essential. It ensures the Composer autoloader is loaded before any tests, so your classes can be found automatically.
colors="true": Makes the terminal output nicer, with green bars for success and red for failures.
<testsuites>: Defines one or more sets of tests.
<testsuite name="Unit">: Names our test suite "Unit".
<directory suffix="Test.php">./tests</directory>: The most important directive. It tells PHPUnit to look for files ending with Test.php inside the ./tests directory.

Now, to run all the tests in your project, you just need to type in the terminal:

./vendor/bin/phpunit

PHPUnit will automatically find and use the phpunit.xml file, running your test suite with the defined configurations.

Next Steps:

You now know how to write more robust and organized tests. In the next module, we will dive into one of the most powerful and sometimes challenging concepts in the world of unit testing: Test Doubles, better known as Mocks and Stubs. This technique is fundamental for isolating your code and testing units that depend on other complex parts of the system.

Module 2: Writing Basic Tests and Assertions

Antonio Silva — Sat, 23 Aug 2025 20:24:06 +0000

Now that you have your environment set up and have run your first test, it's time to deepen your knowledge of writing tests with PHPUnit. In this module, we will explore the structure of a test in more detail and dive into the world of assertions, which are the heart of any test.

1. Structure of a Test

As we saw in the previous module, every test in PHPUnit is a class that extends PHPUnit\Framework\TestCase. Let's take a closer look at the structure:

<?php

// tests/MathTest.php

use PHPUnit\Framework\TestCase;

class MathTest extends TestCase
{
    public function testSumShouldReturnTheCorrectValue()
    {
        // ... test body ...
    }

    public function testSubtractionShouldWorkCorrectly()
    {
        // ... test body ...
    }
}

Important Conventions:

Class Name: The test class usually has the same name as the class being tested, with the suffix Test. For example, to test a Math class, the test class would be MathTest.
Method Name: The name of the test method must begin with the prefix test. A good practice is to make the method name descriptive, indicating what is being tested and what the expected result is. For example, instead of testSum(), use testSumShouldReturnTheCorrectValue(). This makes your tests more readable, and when a test fails, the method name already gives you a clue as to what went wrong.

2. The Power of Assertions

Assertions are the methods you use to verify that the result of your code is what you expect. If an assertion fails, PHPUnit stops the execution of that test and marks it as "failed".

Let's get to know the most common and useful assertions:

a) Checking for Equality:

assertEquals($expected, $actual): Checks if two variables are equal in value. This is by far the most used assertion.

public function testSumShouldReturnTheCorrectValue()
{
    $result = 2 + 3;
    $this->assertEquals(5, $result);
}

assertSame($expected, $actual): Checks if two variables are identical, meaning they have the same type and the same value.

public function testVariableTypes()
{
    $this->assertEquals(5, "5"); // Passes, because the values are equal
    $this->assertSame(5, "5");   // Fails, because the types are different (integer vs. string)
}

b) Checking Boolean Conditions:

assertTrue($condition): Checks if a condition is true.

assertFalse($condition): Checks if a condition is false.

public function testIsEvenNumber()
{
    $number = 4;
    $isEven = ($number % 2 == 0);
    $this->assertTrue($isEven);
}

c) Checking for Nulls:

assertNull($variable): Checks if a variable is null.
assertNotNull($variable): Checks if a variable is not null.

d) Checking Counts and Arrays:

assertCount($expectedCount, $array): Checks if an array has a specific number of elements.

public function testArrayHasThreeItems()
{
    $items = ['apple', 'banana', 'orange'];
    $this->assertCount(3, $items);
}

assertArrayHasKey($key, $array): Checks if an array contains a given key.
assertContains($value, $array): Checks if an array contains a given value.
assertEmpty($variable): Checks if a variable is empty (useful for strings, arrays, etc.).

e) Checking Object Types:

assertInstanceOf($expectedClass, $object): Checks if an object is an instance of a given class.

// Assuming you have a 'User' class
public function testUserCreation()
{
    $user = new User();
    $this->assertInstanceOf(User::class, $user);
}

f) Optional: Adding Custom Error Messages

All assertions accept an optional last argument: a custom error message. If the test fails, this message will be displayed, which can help you understand the problem more quickly.

public function testSumWithErrorMessage()
{
    $result = 2 + 2;
    $this->assertEquals(5, $result, 'The sum of 2 + 2 should be 5, but it was not.');
}

3. Testing Exceptions

Sometimes, the expected behavior of your code is to throw an exception. For example, when trying to divide a number by zero. PHPUnit offers an elegant way to test this:

// In a 'Calculator' class
public function divide($a, $b)
{
    if ($b == 0) {
        throw new InvalidArgumentException('Cannot divide by zero.');
    }
    return $a / $b;
}

// In your test
public function testDivisionByZeroThrowsException()
{
    $this->expectException(InvalidArgumentException::class);
    $this->expectExceptionMessage('Cannot divide by zero.');

    $calculator = new Calculator();
    $calculator->divide(10, 0);
}

expectException(): Tells PHPUnit that you expect an exception of a certain type to be thrown.
expectExceptionMessage(): (Optional) Checks if the exception message is what you expect.

If the expected exception is thrown, the test passes. If no exception is thrown, or if an exception of a different type is thrown, the test fails.

Next Steps:

With this knowledge, you can now write a variety of unit tests for your code. In the next module, we will explore how to organize your tests more effectively, using Data Providers to avoid code repetition and understanding the test lifecycle with the setUp() and tearDown() methods.

Module 1: Introduction to PHPUnit and the World of Testing

Antonio Silva — Sat, 16 Aug 2025 19:15:43 +0000

Welcome to the first module of our PHPUnit course! Here, we'll lay the foundations for your journey into the world of automated testing. By the end of this module, you'll have a clear understanding of what tests are, why they're crucial for developing quality software and how to take your first steps with PHPUnit.

1. What are Automated Tests?

Imagine you're building a house. Before handing it over, you check that the windows open and close, that the taps don't leak and that the electricity works in every room. These are manual tests. In software development, we do something similar.

Manual software testing involves one person running the program and checking that everything works as expected. Although important, this process can be:

Slow and repetitive: Running the same tests with every new change to the code is tiring.
Prone to human error: It's easy to forget to test a specific scenario or make a mistake during verification.
Not scalable: As the software grows, the number of tests required increases exponentially

This is where automated testing comes in. Instead of a person, we write code to test our own code. These tests are run by a program, which checks that the behavior of the software is as expected.

Types of Automated Tests:

There are several types of tests, each with a different focus:

Unit testing: They are the focus of this course. They test the smallest single unit of code (a function, a method or a class). The aim is to ensure that each “piece” of your software works correctly.
Integration Testing: Checks that different units of code work well together. For example, if your “User” class interacts correctly with the “Database” class.
Functional (or End-to-End - E2E) Testing: Simulates the behavior of a real user, testing complete application flows. For example, a functional test could simulate a user logging in, adding a product to the cart and finalizing the purchase.

In this course, our main focus will be on unit tests, as they form the basis of a solid testing strategy and are the ideal starting point for those just starting out.

2. Introducing PHPUnit

PHPUnit is the most popular and widely used testing framework in the PHP ecosystem. It provides a set of tools and a structure for writing and executing tests in an organized and efficient way.

Why PHPUnit?

Community Standard: It is the de facto standard for PHP testing, which means that there is a vast amount of documentation, tutorials and community support available.
Feature-rich: It offers a wide range of features for writing tests, from simple assertions to the creation of “test doubles” (mocks and stubs), which we'll look at later.
Easy integration: Integrates perfectly with popular development tools, such as Composer, and with Continuous Integration (CI/CD) systems.
Detailed Reports: Generates clear reports on test execution, indicating which tests passed, which failed and why.

3. Setting up the environment

To start using PHPUnit, you'll need to have it installed in your project. The recommended way to do this is via Composer, PHP's dependency manager. If you don't have Composer installed yet, you can find the instructions on the official website.

With Composer installed, open the terminal in your project folder and run the following command:

composer require --dev phpunit/phpunit

Let's understand what this command does:

composer require: Tells Composer that you want to add a new dependency to your project.
--dev: This is an important flag. It indicates that PHPUnit is a development dependency, i.e. it is needed to develop and test the application, but does not need to be installed in a production environment.
phpunit/phpunit: This is the name of the PHPUnit package in the Packagist (Composer's package repository).

4. Your First Test

Let's create a simple test to see PHPUnit in action. The most common convention is to have a src (or app) folder for your application code and a tests folder for the tests, mirroring the src structure.

my-project/ 
├── src/ 
│ └── Example.php 
├── tests/ 
│ └── ExampleTest.php 
├── vendor/ 
└── composer.json

1. Class to be tested

Inside the src/ folder, create a file named Example.php.

<?php

namespace App;

class Example
{
    public function sum(int $a, int $b): int
    {
        return $a + $b;
    }
}

2. Create a test file

Inside the tests/ folder, create a file named ExampleTest.php. The convention is to name test files with the Test.php suffix.

<?php

use PHPUnit\Framework\TestCase;
use App\Example;

class ExampleTest extends TestCase
{
    public function testSum()
    {
        $calc = new Example();
        $result = $calc->sum(2, 3);
        $this->assertEquals(5, $result);
    }
}

Let's analyze this code:

use PHPUnit\Framework\TestCase;: Imports the TestCase class from PHPUnit, which all of our test classes must extend.
class ExampleTest extends TestCase: Defines our test class, which extends TestCase.
public function testSum(): This is our test method. The convention is for test method names to start with the test prefix.
$result = $calc->add(2, 3);: The code we want to test.
$this->assertEquals(5, $result);: This is an assertion. We are telling PHPUnit: "I assert that the expected value (5) is equal to the actual value ($result)". If the assertion is true, the test passes. If it's false, the test fails.

3. Configuring autoload (composer.json)

In your composer.json file, add the following:

"autoload": {
    "psr-4": {
        "App\\": "src/"
    }
},
"autoload-dev": {
    "psr-4": {
        "Tests\\": "tests/"
    }
}

Then run:

composer dump-autoload

4. Run the test

Now, in your terminal, from the root of your project, run the following command:

./vendor/bin/phpunit tests

./vendor/bin/phpunit: Executes the PHPUnit executable that was installed by Composer.
tests: Tells PHPUnit to look for and run the tests in the tests/ folder.

If everything went well, you should see output similar to this:

PHPUnit x.x.x by Sebastian Bergmann and contributors.

Runtime:       PHP x.x.x

.                                                                   1 / 1 (100%)

Time: 00:00.024, Memory: 14.00 MB

OK (1 test, 1 assertion)

The dot (.) indicates that a test passed successfully. If the test had failed (for example, if we expected the result to be 5 but it wasn't), the output would be different, showing an F and a detailed error message.

Congratulations! You have just written and executed your first test with PHPUnit. In the next module, we will dive deeper into writing tests and explore the various assertions that PHPUnit offers.

Module 1 Final Challenge

Create a subtract($a, $b) method in the Example class and write a test for it in ExampleTest.

From Form to Mascot: My AI App with Google AI Studio

Antonio Silva — Tue, 15 Jul 2025 22:21:46 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

I built Mascot AI Generator, an intuitive app that allows anyone to generate custom mascot illustrations using structured input fields. Instead of relying on a single prompt, the user fills out a simple form choosing the mascot type, personality, accessories, colors, style, and background and the app uses Google’s Imagen API to render the image.

Prompt I Used to Generate the App

Make a mascot generator based on the prompt provided by the user. Use Imagen to generate the mascot.

User data includes:

Type of creature or animal (e.g. cat, dragon, octopus)

Personality of the mascot (e.g. fun, wise, curious)

Accessories or clothes (e.g. glasses, hat, backpack)

Desired artistic style (e.g. cartoon, pixel art, realistic)

Predominant colors (e.g. blue, yellow)

Desired backdrop (optional)

Demo

Click here to try the Mascote AI Generator

My Experience

Building with Google AI Studio was incredibly smooth and intuitive. The visual editor made it easy to create a useful interface without writing a lot of code, and the Imagen API delivered surprisingly good results based on structured inputs. I learned that offering users a guided prompt experience (via forms) can be just as powerful if not more than letting them type free-form text.

This project taught me how to think in terms of user experience and prompt engineering at the same time. I’m excited to continue experimenting with similar tools and creative AI apps!

Perfect Landing: Brazil's traditional Festas Juninas

Antonio Silva — Sun, 29 Jun 2025 02:13:05 +0000

This is a submission for Frontend Challenge - June Celebrations, Perfect Landing: June Celebrations

What I Built

For this challenge, I created a vibrant and accessible landing page to celebrate Festa Junina, one of the most colorful and joyful traditional festivals in Brazil. It’s a June celebration filled with music, typical foods, folk dances like “quadrilha,” bonfires, and cheerful decorations like paper lanterns and banners.

The landing page is built with semantic HTML and custom CSS, highlighting key sections of the celebration:

The origin of the festival
A list of traditional foods like pamonha, canjica, and curau
Popular activities like the mock wedding and typical games

The design was inspired by real Festa Junina posters, using warm tones, bold fonts, and thematic emojis to reflect the festive spirit.

Demo

Journey

As a Brazilian developer, Festa Junina holds a special place in my heart. I wanted to create something that could reflect its energy, joy, and cultural richness.

I started by sketching the layout based on traditional event flyers, then translated that into HTML/CSS while ensuring accessibility and responsive behavior. Some parts I’m particularly proud of:

The bright color palette that evokes the festive vibe
The layout with flexible sections and mobile responsiveness
The use of accessible semantic elements and emoji decorations

Through this project, I refined my CSS design skills and practiced planning a layout based on cultural references. If I had more time, I would like to add animations (like waving flags) and a form to share favorite Festa Junina memories.

CSS Art: Brazil's traditional Festas Juninas

Antonio Silva — Sun, 29 Jun 2025 00:34:41 +0000

This is a submission for Frontend Challenge - June Celebrations, CSS Art: June Celebrations.

Inspiration

My inspiration came from Brazil's traditional Festas Juninas, a joyful and colorful celebration that takes place throughout the month of June. It's a time marked by flags, gangs, bonfires, typical food and lots of balloons in the sky. I wanted to capture this energy using only HTML and CSS, creating a small animated universe that harks back to childhood, community and dance.

Demo

Journey

I started with the simple idea of animated balloons floating around, but quickly wanted to bring the scene to life. I added variations in color, depth and movement using transform, z-indexand opacity, which brought a touch of realism and visual depth.

Then I felt that something was missing, so I included a dancing silhouette, representing the traditional quadrilha dances of the Festas Juninas. This part was a bit of a creative challenge with divs, clip-path, pseudo-elements and CSS animations to simulate the body in motion.

It was a fun exercise in pure CSS, without SVGs or JavaScript, which forced me to explore the limits of shapes and animations with native code. I was especially happy with the festive mood of the artwork and the visual atmosphere I managed to create.

💡 Team Submission: This is an individual creation. No team participated in this submission.

For the next steps, I'm thinking of making the artwork responsive, adding June music and perhaps integrating an interactive version with click and drag balloon events. I also want to experiment with dynamic shadows and bonfire lights!

PHP Design Patterns: Remote Facade

Antonio Silva — Sat, 29 Mar 2025 20:36:04 +0000

Remote Facade Design Pattern

The Remote Facade design pattern is used to reduce the number of remote calls between the client and the server. It acts as a single entry point to the underlying subsystem, offering coarse-grained methods that aggregate and manage the details of more complex operations. This pattern helps minimize latency issues caused by multiple network requests by wrapping complex processes inside a unified interface.

In PHP, the Remote Facade pattern is particularly useful in cases where the server provides a RESTful API or web services to a client.

How It Works

The Facade class simplifies the interaction with various subsystems or services.
The client makes a single call to the Facade instead of multiple fine-grained calls.
The Facade coordinates with underlying services, performs any necessary data processing, and returns a simpler response to the client.

Implementation

Let's create a detailed example of the Remote Facade pattern using PHP, simulating a real-world e-commerce system with a REST API. This example will cover:

Subsystem Services: Separate services for users, orders, and inventory.
Remote Facade: A class that acts as a single entry point for the client.
Client Request: Simulating how a client (like a frontend or mobile app) interacts with the API.

Folder Structure

ecommerce-app/
│── public/                  # Public-facing directory
│   ├── index.php            # Main entry point
│
│── src/                     # Core application logic
│   ├── Services/            # Subsystems (fine-grained remote services)
│   │   ├── UserService.php
│   │   ├── OrderService.php
│   │   ├── InventoryService.php
│   │
│   ├── Facade/              # Remote Facade
│   │   ├── ECommerceFacade.php
│   │
│   ├── Config/              # Configuration files (optional)
│   │   ├── config.php
│
│── api/                     # API layer (if exposing via REST)
│   ├── dashboard.php        # API endpoint using the facade
│
│── tests/                   # Unit tests for services and facade
│
│── vendor/                  # Composer dependencies (if used)
│
│── composer.json            # PHP dependency manager file

Setting Up Autoloading

To make namespaces work, configure Composer.

{
    "autoload": {
        "psr-4": {
            "Services\\": "src/Services/",
            "Facade\\": "src/Facade/"
        }
    }
}

composer dump-autoload

1️⃣ Implementing the Folder Structure

1.1 - src/Services/ (Subsystem Services)

Each service simulates a remote API or database call.

src/Services/UserService.php

<?php
namespace Services;

class UserService {
    /**
     * Get user information by user ID.
     *
     * @param int $userId
     * @return array
     */
    public function getUserInfo(int $userId): array {
        // Simulate data fetched from a database or external API
        return [
            'id' => $userId,
            'name' => 'Alice Johnson',
            'email' => 'alice@example.com',
            'loyaltyPoints' => 120
        ];
    }
}

src/Services/OrderService.php

<?php
namespace Services;

class OrderService {
    /**
     * Get the user's most recent orders.
     *
     * @param int $userId
     * @return array
     */
    public function getRecentOrders(int $userId): array {
        // Simulate order data (e.g., from a database or API)
        return [
            [
                'orderId' => 101,
                'status' => 'Delivered',
                'totalAmount' => 250.50
            ],
            [
                'orderId' => 102,
                'status' => 'Pending',
                'totalAmount' => 89.99
            ]
        ];
    }
}

src/Services/InventoryService.php

<?php
namespace Services;

class InventoryService {
    /**
     * Check the stock level of a given product.
     *
     * @param int $productId
     * @return array
     */
    public function checkStock(int $productId): array {
        // Simulate stock information
        return [
            'productId' => $productId,
            'stockLevel' => 15,
            'reorderThreshold' => 5
        ];
    }
}

1.2 - src/Facade/(Remote Facade)

This ECommerceFacade.php aggregates responses from multiple services.

src/Facade/ECommerceFacade.php

<?php
namespace Facade;

use Services\UserService;
use Services\OrderService;
use Services\InventoryService;

/**
 * ECommerceFacade simplifies interactions with multiple services.
 * This is the Remote Facade entry point for client applications.
 */
class ECommerceFacade {
    private UserService $userService;
    private OrderService $orderService;
    private InventoryService $inventoryService;

    /**
     * Constructor initializes the service objects.
     */
    public function __construct() {
        $this->userService = new UserService();
        $this->orderService = new OrderService();
        $this->inventoryService = new InventoryService();
    }

    /**
     * Get dashboard data for a user, including user info,
     * recent orders, and stock info for a selected product.
     *
     * @param int $userId
     * @param int $productId
     * @return array
     */
    public function getDashboardData(int $userId, int $productId): array {
        // Retrieve user information
        $userInfo = $this->userService->getUserInfo($userId);

        // Retrieve user's recent orders
        $recentOrders = $this->orderService->getRecentOrders($userId);

        // Retrieve stock information for a specific product
        $productStock = $this->inventoryService->checkStock($productId);

        // Aggregate and return the data to the client
        return [
            'user' => $userInfo,
            'recentOrders' => $recentOrders,
            'productStock' => $productStock
        ];
    }
}

2️⃣ Exposing as an API

If you want to use this in an API, create an api/dashboard.php file.

api/dashboard.php

<?php
require_once __DIR__ . '/../vendor/autoload.php';

use Facade\ECommerceFacade;

// Set response type to JSON
header('Content-Type: application/json');

// Retrieve query parameters (with defaults)
$userId = $_GET['userId'] ?? 1;
$productId = $_GET['productId'] ?? 2001;

// Create the facade instance
$facade = new ECommerceFacade();

// Get the dashboard data using the facade
$data = $facade->getDashboardData((int) $userId, (int) $productId);

// Output the data as JSON
echo json_encode($data, JSON_PRETTY_PRINT);

📌 To test the API, start a local PHP server and visit:

http://localhost:8000/api/dashboard.php?userId=1&productId=2001

{
  "user": {
    "id": 1,
    "name": "Alice Johnson",
    "email": "alice@example.com",
    "loyaltyPoints": 120
  },
  "recentOrders": [
    {
      "orderId": 101,
      "status": "Delivered",
      "totalAmount": 250.5
    },
    {
      "orderId": 102,
      "status": "Pending",
      "totalAmount": 89.99
    }
  ],
  "productStock": {
    "productId": 2001,
    "stockLevel": 15,
    "reorderThreshold": 5
  }
}

3️⃣ Running the Application

If you don’t want an API and just want to test the facade, use public/index.php:

public/index.php

<?php
require_once __DIR__ . '/../vendor/autoload.php';

use Facade\ECommerceFacade;

// Create the facade instance
$facade = new ECommerceFacade();

// Fetch dashboard data
$data = $facade->getDashboardData(1, 2001);

// Print results to browser (for testing purposes)
echo "<pre>";
print_r($data);
echo "</pre>";

Start a local server:

php -S localhost:8000 -t public

Array
(
    [user] => Array
        (
            [id] => 1
            [name] => Alice Johnson
            [email] => alice@example.com
            [loyaltyPoints] => 120
        )

    [recentOrders] => Array
        (
            [0] => Array
                (
                    [orderId] => 101
                    [status] => Delivered
                    [totalAmount] => 250.5
                )

            [1] => Array
                (
                    [orderId] => 102
                    [status] => Pending
                    [totalAmount] => 89.99
                )

        )

    [productStock] => Array
        (
            [productId] => 2001
            [stockLevel] => 15
            [reorderThreshold] => 5
        )

)

Why Use Remote Facade?

✅ Reduces multiple API calls → Instead of calling three services separately, the client makes a single request.
✅ Encapsulates complex logic → The client does not need to worry about how the data is fetched or aggregated.
✅ Improves performance → Reduces network latency by combining responses.
✅ Enhances maintainability → Changes to services do not affect the client, as long as the facade interface remains stable.

When Should You Use This Pattern?

🔹 When you have a distributed system with multiple microservices.
🔹 When your client should not directly interact with complex subsystems.
🔹 When you want to minimize network requests and improve performance.

DEV Community: Antonio Silva

Primeiro Livro Publicado

Responsive Images in HTML

What Are Responsive Images?

Basic Responsiveness with CSS

Smart Responsiveness with srcset

Using the <picture> Element (The Modern & Powerful Approach)

Difference Between srcset Using w and x

Common Issues and How to Avoid Them

When to Use Each Technique

How to create and publish your own packages on Packagist

What Is Packagist?

Requirements

Step 1 — Basic Package Structure

Step 2 — Create the composer.json File

Step 3 — Test the Autoload Locally

Step 4 — Push the Project to GitHub

Step 5 — Publish on Packagist

Step 6 — Enable Automatic Updates via GitHub Hook

Step 7 — Using Your Package in Another Project

Final Tips

Module 5: Advanced Topics and Best Practices

Module 4: Uncovering Test Doubles (Mocks and Stubs)

1. What are Test Doubles?

2. Stubs: Simulating Behavior (State Control)

3. Mocks: Verifying Interactions (Behavior Verification)

4. Crucial Differences: Mocks vs. Stubs

5. Other Doubles: Fakes and Spies

Module 3: Deepening Your Testing Knowledge

Module 3: Deepening Your Testing Knowledge

1. Data Providers: Test More with Less Code

2. Fixtures and the Test Lifecycle: setUp() and tearDown()

3. Organizing Your Tests: The phpunit.xml File

Module 2: Writing Basic Tests and Assertions

1. Structure of a Test

2. The Power of Assertions

3. Testing Exceptions

Module 1: Introduction to PHPUnit and the World of Testing

1. What are Automated Tests?

2. Introducing PHPUnit

3. Setting up the environment

4. Your First Test

Module 1 Final Challenge

From Form to Mascot: My AI App with Google AI Studio

What I Built

Prompt I Used to Generate the App

Demo

My Experience

Perfect Landing: Brazil's traditional Festas Juninas

What I Built

Demo

Journey

CSS Art: Brazil's traditional Festas Juninas

Inspiration

Demo

Journey

PHP Design Patterns: Remote Facade

Remote Facade Design Pattern

How It Works

Implementation

Why Use Remote Facade?

When Should You Use This Pattern?

Smart Responsiveness with `srcset`

Using the `<picture>` Element (The Modern & Powerful Approach)

Difference Between `srcset` Using w and x

Step 2 — Create the `composer.json` File

2. Fixtures and the Test Lifecycle: `setUp()` and `tearDown()`

3. Organizing Your Tests: The `phpunit.xml` File