—

Let’s imagine that we’re working on e-commerce platform. Each user can sold maximum 100 items How to do it properly? How to introduce domain limit on doctrine relationships? How can I introduce it? Let’s use rich entities (trying to follow Domain-Driven-Design and Test-Driven-Development rules):

<?php

use Doctrine\Common\Collections\ArrayCollection;
use Doctrine\Common\Collections\Collection;
use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity]
#[ORM\Table(name: 'users')]
class User
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column(type: 'integer')]
    private int|null $id = null;

    #[ORM\Column(type: 'string', length: 255)]
    private string $name;

    /** @var Collection<int, Item> */
    #[ORM\OneToOne(inversedBy: 'createdBy', targetEntity: Item::class)]
    private Collection $items;

    public function __construct(string $name)
    {
        $this->name = $name;
        $this->items = new ArrayCollection();
    }

    public function addItem(Item $item): void
    {
        $this->items[] = $item;
    }

    public function getItems(): Collection
    {
        return $this->items;
    }
}

and item:

<?php

use Doctrine\ORM\Mapping as ORM;

class Item
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column(type: 'integer')]
    private int|null $id = null;

    #[ORM\Column(type: 'string')]
    private string $description;

    #[ORM\Column(type: 'integer')]
    private int $price;

    #[ORM\ManyToOne(targetEntity: User::class, inversedBy: 'items')]
    private User $createdBy;

    public function __construct(string $description, int $price)
    {

    }

    public function setCreator(User $createdBy): void
    {
        $createdBy->addItem($this);
        $this->createdBy = $createdBy;
    }
}

And basic test for that:

<?php

namespace tests;

use Item;
use PHPUnit\Framework\TestCase;
use User;

final class ItemsLimitPerUserTest extends TestCase
{
    public function testItemsLimitPerUser(): void
    {
        $user = new User('John');
        $itemA = new Item('My aswesome item A', 20);
        $itemB = new Item('My aswesome item B', 20);
        $itemC = new Item('My aswesome item C', 20);

        $itemA->setCreator($user);
        $itemB->setCreator($user);
        $itemC->setCreator($user);

        $this->assertEquals(
            3,
            $user->getItems()->count()
        );
    }
}

Now let’s add new test case that adding fourth item will fail (let’s set limit = 3). Basically we will implement items limit per user logic.

public function testItemsLimitPerUserIsMet(): void
{
    $user = new User('John');
    $itemA = new Item('My aswesome item A', 20);
    $itemB = new Item('My aswesome item B', 20);
    $itemC = new Item('My aswesome item C', 20);
    $itemD = new Item('My aswesome item D', 20);

    $itemA->setCreator($user);
    $itemB->setCreator($user);
    $itemC->setCreator($user);

    try {
        $itemD->setCreator($user);
    } catch (Exception $exception) {
        $this->assertInstanceOf(LimitMetException::class, $exception);
    }

    $this->assertEquals(
        3,
        $user->getItems()->count()
    );
}

Which obviously will fail for that moment:

~/Development/doctrine-playground$ ./vendor/bin/phpunit tests
PHPUnit 11.5.6 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.2.27

.F                                                                  2 / 2 (100%)

Time: 00:00.007, Memory: 8.00 MB

There was 1 failure:

1) tests\ItemsLimitPerUserTest::testItemsLimitPerUserIsMet
Failed asserting that 4 matches expected 3.

/home/adt/Development/doctrine-playground/tests/ItemsLimitPerUserTest.php:48

FAILURES!
Tests: 2, Assertions: 2, Failures: 1.

Now let’s try to implement this requirement (git diff):

diff --git a/src/User.php b/src/User.php
index ec83b61..d8dcde8 100644
--- a/src/User.php
+++ b/src/User.php
@@ -8,6 +8,8 @@ use Doctrine\ORM\Mapping as ORM;
 #[ORM\Table(name: 'users')]
 class User
 {
+    public const ITEMS_LIMIT = 3;
+
     #[ORM\Id]
     #[ORM\GeneratedValue]
     #[ORM\Column(type: 'integer')]
@@ -26,8 +28,15 @@ class User
         $this->items = new ArrayCollection();
     }
 
+    /**
+     * @throws LimitMetException
+     */
     public function addItem(Item $item): void
     {
+        if ($this->items->count() >= self::ITEMS_LIMIT) {
+            throw new LimitMetException();
+        }
+
         $this->items[] = $item;
     }

Now, all tests are passing:

~/Development/doctrine-playground$ ./vendor/bin/phpunit tests
PHPUnit 11.5.6 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.2.27

..                                                                  2 / 2 (100%)

Time: 00:00.003, Memory: 8.00 MB

OK (2 tests, 3 assertions)

But we have one issue, during adding new item doctrine by default will load whole items collection. It’s not good to load it only to do the count. For that we can use Extra lazy feature from Doctrine ORM:

    /** @var Collection<int, Item> */
    #[ORM\OneToOne(inversedBy: 'createdBy', targetEntity: Item::class, fetch: 'EXTRA_LAZY')]
    private Collection $items;

git diff:

diff --git a/src/User.php b/src/User.php
index d8dcde8..194fe67 100644
--- a/src/User.php
+++ b/src/User.php
@@ -19,7 +19,7 @@ class User
     private string $name;
 
     /** @var Collection<int, Item> */
-    #[ORM\OneToOne(inversedBy: 'createdBy', targetEntity: Item::class)]
+    #[ORM\OneToOne(inversedBy: 'createdBy', targetEntity: Item::class, fetch: 'EXTRA_LAZY')]
     private Collection $items;

Now doctrine won’t load all entities into memory to simply count them, it will do dedicate count SQL query. In that way you can introduce limit for really large entity collections and avoid hitting memory limit and performance issues.

The post How to do performant count of child entities in rich entity with doctrine? appeared first on Angry dev thoughts.

The post We should be able to write test for every bug reported showcasing bug appeared first on Angry dev thoughts.

In general I don’t think so there should be auto rules, like new service = new microservice.

The post Starting development of new feature by creating new micro service does not make sense in most cases appeared first on Angry dev thoughts.

 session.cookie_lifetime int

session.cookie_lifetime specifies the lifetime of the cookie in seconds which is sent to the browser. The value 0 means “until the browser is closed.” Defaults to 0.

https://www.php.net/manual/en/session.configuration.php#ini.session.cookie-lifetime

 session.gc_maxlifetime int 

session.gc_maxlifetime specifies the number of seconds after which data will be seen as ‘garbage’ and potentially cleaned up. Garbage collection may occur during session start (depending on session.gc_probability and session.gc_divisor). Defaults to 1440 (24 minutes).

https://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime

Sometimes I see that people set PHP session cookie lifetime however it does not increase security and only annoys people. Like if set expiration to 24h then when you logged on at 10 AM you will be logged out at 10 AM next day, no matter what.

The post How to make PHP session sticky/auto renew on last activity appeared first on Angry dev thoughts.

So, we should avoid interfaces with one implementation, right?

From my experience interfaces with one implementation should be avoided. I sometimes hear this explanations from people adding interface with one implementation:

• when I have inerfaces (even with one implementation) code is decoupled – seriously? Adding interfaces changes anything? In my opinion no. If there is need for coupling and there is coupling in real life then it probably should be depicted in the code.
• when I have inerfaces (even with one implementation) testing is easier – I can agree with that, however when I saw code people stating that in tests I did not see implementation of this interface Like RepositoryInterface and InMemoryRepository implements RepositoryInterface, and what they do is just creating another mock with mocking library
• when I have inerfaces (even with one implementation) when I will need second implementation it will be easier – happend zero times in my over 10 years experience. Usually abstraction that you will make based on one case won’t fit more cases. That is why I propose to wait with creating abstractions till you will be able to notice the pattern (at least 3 cases)
• when I have inerfaces (even with one implementation) it isolates parts of the system – I can sometimes agree, but usually what I see is the interface that contains whole public API of given class and what is more is changed with the same pace as given concrete class (bruh)

So what’s wrong with interface with one implementation?

In my opinion the less code we write the better, so I don’t like interfaces with one implementation because:

• they make navigation trough code harder,
• you have more code,
• they hide real dependency even if there is only one implementation

So when to use interface?

From my experience creating abstraction is really hard. That is why I advice to wait till more cases, so you can notice and validate pattern. In general I think that creating interfaces with one implementation is misinterpeetation of DIP from SOLID, here is quote from Uncle Bob:

The need to mock every class interaction forces an explosion of polymorphic interfaces. In statically typed languages like Java, that means the creation of lots of extra interface classes whose sole purpose is to allow mocking. This is over-abstraction and the dreaded “design damage”.

https://blog.cleancoder.com/uncle-bob/2014/05/10/WhenToMock.html

The post I don’t believe dependency inversion princpile makes sense in most cases appeared first on Angry dev thoughts.

I think it is sometimes proposed and forced by non-tech scrum masters, because they think it needs to be that way. It annoys me. It does not have to be like that.

I really prefer to have a linear scale (with step 1), like:

• 1 story point – around 1 day of development
• 2 story points – around 2 days of development
• 3 story points – around 3 days of development
• 4 story points – around 4 days of development

etc. In that way you can really see how much work will fit into sprit.

Do not estimate bugs

Sometimes I hear do not estimate bugs – and I always think WTF? Without estimating bugs you’re not able to asses how many of them you are able to take into sprint. Something different is to fix bug that wrong image is shown and something different is to track why wrong price is calculated at the end of quarter. So it should be visible, how much do you expect them to differ. In my opinion esimating bugs is just fine

Average story points per sprint

With usage of story points constrained to values from fibonacci sequence you cannot do regular maths on that numbers. Why? Because they are not proportional. So using arithmetic mean will not give you reliable results. Probably you heard many times why this time we planned sprint using artiehmetic mean from pasts sprints and we still did not deliver all stories. Sounds familiar?

The post Estimating stories using story points with Fibonacci sequence doesn’t make sense. appeared first on Angry dev thoughts.

At the same time I don’t believe that we should blindly follow 100% of code coverage. As a result we can see test which tests if programming language works. Sometimes making tests testing line by line what our code does.

Creating many mocks makes refactoring harder, and having 1:1 test -> production relation doesn’t help.

In addition having 1:1 to test => production code relation can create so many test cases that they are will be slower than unit tests of groups of classes (ie Angular testing)

As a rule of thumb I prefer to write tests that can test as much production code as possible. So to have:

(lines of production code tested) / (lines of code test) ratio as high as possible.

And I call this test effectiveness ratio (TER).

Many mocks make refactoring harder

I do not like mocking, because extensive mocking leads to situation that with every change in code you need to change many mocks. Ideal situation for me is I can do refactor without touching tests (because I did not change behaviour)

The post I don’t think that unit test with mocking everything around is good idea appeared first on Angry dev thoughts.