While working on the next post of The Software Architecture Chronicles I ended up creating a little symfony bundle which I called hgraca/doctrine-test-db-regeneration-bundle to generate and regenerate the tests database used by a phpunit tests suite.
It is inspired by some code that Luis Cobucci wrote back in 2017, and it uses the Doctrine fixtures to generate a backup of the tests DB, which is then put in place just before every test method and removed just after every test method.
It has 3 options:
- We can opt to use an existing tests DB backup, if it is available. This saves us the time to generate the DB, but it will not be useful if we want to test queries that are based on time like “select all users created in the last hour” because if the backup is older than 1h our tests will fail;
- We can opt to not put in place a new copy of the DB at the beginning of a test method, so that we can safely use the DAMA\DoctrineTestBundle together with this bundle;
- We can opt to not remove the DB at the end of a test method, so that we can safely use the DAMA\DoctrineTestBundle together with this bundle.
You can check out the bundle here: hgraca/doctrine-test-db-regeneration-bundle
Hope it’s useful for more people and constructive feedback is always welcome.
Typically, in a layered architecture, the top layers are aware of the lower layers and start logic in the lower layers. But, the lower layers are not aware of the layers above and can not start logic in the layers above. However, in highly complex situations, the lower layers might need to fire logic in the top layers.
Continue reading “When to use events” →
Naming a class as ProductProperties, instead of simply Properties despite the namespace refer it to be in the Product namespace, does NOT defeat the purpose of the namespaces.
Namespaces are supposed to prevent clashes in class naming, to prevent ambiguity at a auto-loading level. They do not prevent ambiguity at a development level.
If at development I see a class named Properties, I will assume it to be Properties. Would any dev go look at the top of the file for the “use bladibla” to make sure about what class it is? I dont think so. However, that Properties class might actually be the ProductProperties, or the CategoryProperties, or something else. So a class name should be as accurate and unambiguous as possible, independently of the namespace.
Bottom line: If its a Properties class, name it Properties, but if it is a ProductProperties class, name it ProductProperties!
I stumbled upon the situation where I have a functional test that puts a job in a queue and tests the result of it being processed.
But in testing environment I don’t want the queue consumer to be permanently running, so the test would need to start the queue consumer, wait until it does its thing, and later stop it.
Continue reading “Launching a separate process from PHP” →
So I have a DB being created automatically for me using Symfony and Doctrine. Now I want to add some initial data so that I can actually develop some code to use the DB.
We do this by using the doctrine-fixtures-bundle to create classes that will load some data into our tables.
Continue reading “Adding fixtures to the DB using Symfony2 and Doctrine” →
So I’m starting a new project now, I’ve set up the logger, I’ve set up the mailing, and now it’s time I start to set up the model layer with Doctrine. In Symfony2 you can choose to have the configuration of this layer in xml files, yml files or as annotations directly in the entities classes. Personaly I find xml files too verbose, and annotations put logic in the entities which makes them less readable and if we want to change ORM we will have Doctrine configurations in entities that do not deal with Doctrine, so I prefer to have the configurations in yml files. Symfony has some documentation on how to set this up, but its not complete, as far as I can remember it only has documentation about one to many relationships, but in real life situations we rarely find only those types of relationships in a DB schema, so here I will document how to configure one to one, one to many, many to many and many to many to many relationships.
Continue reading “Creating relationships between entities with Symfony2, Doctrine and yml” →
Sure, swiftmailer already comes pre configured when you install symfony2.
However, it doesn’t really work out of the box, I mean, if we just make some code to send an email no email is sent…
Continue reading “Setting up swiftmailer in Symfony2” →
It seems there’s a bug in Symfony, when updating to Monolog Bundle 2.5.0 that causes this if you do not have the ‘spool’ config value set under the swiftmailer configuration.
Continue reading “Symfony bug: ‘dependency on a non-existent service “swiftmailer.transport.real”‘” →
Properly setting up a logging system for your application is essential for its maintainability, debugging and monitoring.
That being said, what we ideally want in a logging system is the following:
- Only log our application messages, don’t log symphony stuff;
- Log to a different file per environment (dev.log, test.log, prod.log);
- Log to the console, when we run the app through the command line. This way we see feedback immediately, we don’t need to have another window open with tail -f dev.log. With this we can also automate the feedback the app gives back tot he user;
- Also log specific jobs to a specific file, so we have a log per job;
- On Production it should also send us an email if something goes wrong.
Continue reading “How to set up a proper logger in Symfony2” →
At some point in an action, we want to show the user the view of another action.
public function someAction()
/* some genius code ...*/