Monolog: Monolog is a logging library for PHP used by Symfony.
Cookbook: http://symfony.com/doc/current/cookbook/logging/monolog.html
LexikMonologBrowserBundle: https://github.com/lexik/LexikMonologBrowserBundle
This Symfony2 bundle provides a Doctrine DBAL handler for Monolog and a web UI to display log entries.
I am using an existing Doctrine configuration in config.yml:
#config.yml
default:
driver: "%database_driver%"
host: "%database_host%"
port: "%database_port%"
dbname: "%database_name%"
user: "%database_user_prod%"
password: "%database_password_prod%"
charset: UTF8
logging: false
profiling: false
If you do not have the last two lines, you should add them to avoid circular reference error.
And also add lexik_monolog_browser config to use the existing Doctrine connection:
lexik_monolog_browser:
doctrine:
connection_name: default
table_name: monolog_entries
Generatate the table in the database:
>php app/console lexik:monolog-browser:schema-create
Add the below to config_dev.yml and/or config_prod.yml in order for Monolog to use our handler to save into database.
# app/config/config_prod.yml # or any env
monolog:
handlers:
main:
type: fingers_crossed # or buffer
level: error
handler: lexik_monolog_browser
app:
type: buffer
action_level: info
channels: app
handler: lexik_monolog_browser
deprecation:
type: buffer
action_level: warning
channels: deprecation
handler: lexik_monolog_browser
lexik_monolog_browser:
type: service
id: lexik_monolog_browser.handler.doctrine_dbal
Import routes to app/config/routing.yml:
# app/config/routing.yml
lexik_monolog_browser:
resource: "@LexikMonologBrowserBundle/Resources/config/routing.xml"
prefix: /admin/monolog
More:
It would be good to save in logs also the current user. For this you can add in your controller:
//log current user in Monolog
$logger = $this->get('logger');
$logger->info('Current user is : ' . $this->getUser()->getUsername());
Cristian Pana - personal blog on software development, PHP, Symfony Framework, web technologies.
Tuesday, February 23, 2016
Friday, February 5, 2016
Why and how to use services in Symfony
Controllers
Symfony follows the philosophy of “thin controllers and fat models”.
This means that controllers should hold just the thin layer of glue-code
needed to coordinate the different parts of the application.
As a rule of thumb, you should follow the 5-10-20 rule, where controllers should only define 5 variables or less, contain 10 actions or less and include 20 lines of code or less in each action. This isn't an exact science, but it should help you realize when code should be refactored out of the controller and into a service. Source: http://symfony.com/doc/current/best_practices/controllers.html
A unit test is a test against a single PHP class, also called a unit. If you want to test the overall behavior of your application, then use Functional Tests. Because controllers glue together the different parts of the applications they are not usually tested with Unit Tests, instead they are tested with Functional Tests.
As a rule of thumb, you should follow the 5-10-20 rule, where controllers should only define 5 variables or less, contain 10 actions or less and include 20 lines of code or less in each action. This isn't an exact science, but it should help you realize when code should be refactored out of the controller and into a service. Source: http://symfony.com/doc/current/best_practices/controllers.html
A unit test is a test against a single PHP class, also called a unit. If you want to test the overall behavior of your application, then use Functional Tests. Because controllers glue together the different parts of the applications they are not usually tested with Unit Tests, instead they are tested with Functional Tests.
Organizing Your Business Logic
Useful info: http://symfony.com/doc/current/best_practices/business-logic.html
It is very easy to start writing business logic into controller, but this way we will end up with a large function, difficult to read which will break separation of concerns principle https://en.wikipedia.org/wiki/Separation_of_concerns and makes it impossible to test only the business logic.
In order to better organize the code, additional classes should be created. Let's take as an example a class that handles file uploading. Basically it receives the $file uploaded in form and the path where to save the file with a unique name in order to avoid collisions with previous uploaded files. The function returns the name of the file saved on the disk to be persisted in database.
In your controller, the FileUpload class will be used like this:
It is very easy to start writing business logic into controller, but this way we will end up with a large function, difficult to read which will break separation of concerns principle https://en.wikipedia.org/wiki/Separation_of_concerns and makes it impossible to test only the business logic.
In order to better organize the code, additional classes should be created. Let's take as an example a class that handles file uploading. Basically it receives the $file uploaded in form and the path where to save the file with a unique name in order to avoid collisions with previous uploaded files. The function returns the name of the file saved on the disk to be persisted in database.
namespace YourBundle\Utils; Class FileUpload { public function upload(\Symfony\Component\HttpFoundation\File\UploadedFile $file, $uploadDir) { // Generate a unique name for the file before saving it $fileName = md5(uniqid()).$file->guessExtension(); // Move the file to the directory where uploads are stored $file->move($uploadDir, $fileName); // Update the 'Attachement' property to store the file name // instead of its contents return $fileName; } }The file uploading method is based on this article from documentation: http://symfony.com/doc/current/cookbook/controller/upload_file.html
In your controller, the FileUpload class will be used like this:
use YourBundle\Utils\FileUpload;
....
public function createAction(Request $request)
{
....
if ($form->isValid()) {
// $file stores the uploaded file
// @var Symfony\Component\HttpFoundation\File\UploadedFile $file
$file = $product->getBrochure();
// Obtain from parameters the directory where brochures are stored
$uploadDir = $this->container->getParameter('kernel.root_dir').'/../web/uploads/brochures';
//use FileUpload class
$uploader= new FileUpload();
$fileName = $uploader->upload($file, $uploadDir);
// Update the 'brochure' property to store the file name
// instead of its contents
$product->setBrochure($fileName);
// ... persist the $product variable or any other work
return $this->redirect($this->generateUrl('app_product_list'));
}
.....
}
OK, so now we have a testable function upload() which can be tested
independently from the rest of the controller, we just need a mock
object of type 'Symfony\Component\HttpFoundation\File\UploadedFile' and a
path.
Maintaining the code
Parameters
We are very happy with the result and we started using this class in all
controllers, just that at some point we receive a request to change
the path where to save the file uploaded. This means we need to search
in all controllers and change this line:
In order to prevent this in future we can declare a parameter in a local parameters.yml which is imported in the global one:
and use it in all controllers:
$uploadDir = $this->container->getParameter('kernel.root_dir').'/../web/uploads/brochures';
In order to prevent this in future we can declare a parameter in a local parameters.yml which is imported in the global one:
parameters:
yourbundle.upload_dir: '%kernel.root_dir%/../web/uploads/attachments/YourBundle/Upload'
and use it in all controllers:
$uploadDir = $this->container->getParameter('yourbundle.upload_dir');
Dependencies
Now we are happy again and think nothing bad can happen to our code :).
But then again there is a request to save the files to a second path, a
Back Up folder let's say. We could do this by adding a third parameter
in the upload() function:
And we have to modify in all controllers where we are using this function. We will declare this BackUp dir as a parameter also and use it like this:
So we realize that injecting dependencies directly in our function is not a solution. Usually the recommended way to inject dependencies is in constructor definition or by using setters. Let's inject dependencies in constructor:
public function upload(\Symfony\Component\HttpFoundation\File\UploadedFile $file, $uploadDir, $uploadDirBackUp)
And we have to modify in all controllers where we are using this function. We will declare this BackUp dir as a parameter also and use it like this:
$uploadDirBackUp = $this->container->getParameter('yourbundle.upload_dir_backup');
$fileName = $uploader->upload($file, $uploadDir, $uploadDirBackUp);
So we realize that injecting dependencies directly in our function is not a solution. Usually the recommended way to inject dependencies is in constructor definition or by using setters. Let's inject dependencies in constructor:
namespace YourBundle\Utils;
Class FileUpload
{
$uploadDir;
$uploadDirBackUp;
public function __construct($uploadDir, $uploadDirBackUp)
{
$this->uploadDir = $uploadDir;
$this->uploadDirBackUp = $uploadDirBackUp;
}
public function upload(\Symfony\Component\HttpFoundation\File\UploadedFile $file)
{
// Generate a unique name for the file before saving it
$fileName = md5(uniqid()).$file->guessExtension();
// Move the file to the directory where uploads are stored
$file->move($this->uploadDir, $fileName);
....
}
}
Even if the dependencies are injected in constructor, we would still have to modify all the controllers:use YourBundle\Utils\FileUpload;
....
public function createAction(Request $request)
{
....
// Move the file to the directory where brochures are stored
$uploadDir = $this->container->getParameter('yourbundle.upload_dir');
$uploadDirBackUp = $this->container->getParameter('yourbundle.upload_dir_backup');
$uploader= new FileUpload($uploadDir,$uploadDirBackUp);
$fileName = $uploader->upload($file);
.....
}
The solution? Creating a service!
What is a Service?
Put simply, a Service is any PHP object that performs some sort of
“global” task. It's a purposefully-generic name used in computer science
to describe an object that's created for a specific purpose (e.g.
delivering emails). Each service is used throughout your application
whenever you need the specific functionality it provides. You don't have
to do anything special to make a service: simply write a PHP class with
some code that accomplishes a specific task. Congratulations, you've
just created a service!
As a rule, a PHP object is a service if it is used globally in your application. A single Mailer service is used globally to send email messages whereas the many Message objects that it delivers are not services. Similarly, a Product object is not a service, but an object that persists Product objects to a database is a service.
A Service Container (or dependency injection container) is simply a PHP object that manages the instantiation of services (i.e. objects).
Source: http://symfony.com/doc/current/book/service_container.html
As a rule, a PHP object is a service if it is used globally in your application. A single Mailer service is used globally to send email messages whereas the many Message objects that it delivers are not services. Similarly, a Product object is not a service, but an object that persists Product objects to a database is a service.
A Service Container (or dependency injection container) is simply a PHP object that manages the instantiation of services (i.e. objects).
Source: http://symfony.com/doc/current/book/service_container.html
Create the service
In your bundle create a file called services.yml under Resources\config
Note: make sure that your bundle is not configured to expect a XML (services.xml) file in YourBundle\DependencyInjection\YourExtension.php:
$loader = new Loader\YamlFileLoader($container, new FileLocator(DIR__.'/../Resources/config'));
services:
yourbundle_file_upload_service:
class: YourBundle\Utils\FileUpload
arguments: ['%yourbundle.upload_dir%','%yourbundle.upload_dir_backup%' ]
Now the class will not be directly instantiated, instead we will access it from the container. In controller: $fileUpload = $this->get('yourbundle_file_upload_service');
$fileName = $fileUpload->upload($file);
What we've accoplished? Now each time we want to add or modify a
dependency we need to edit just in two places: in the services.yml file
and in the contruct() function. Note: make sure that your bundle is not configured to expect a XML (services.xml) file in YourBundle\DependencyInjection\YourExtension.php:
$loader = new Loader\YamlFileLoader($container, new FileLocator(DIR__.'/../Resources/config'));
$loader->load('services.yml');
Monday, February 1, 2016
About testing
1. Testing in Symfony
Roughly speaking, there are two types of test. Unit testing allows you
to test the input and output of specific functions. Functional testing
allows you to command a “browser” where you browse to pages on your
site, click links, fill out forms and assert that you see certain things
on the page.
1.1. Unit Tests
Unit tests are used to test your “business logic”, which should live in
classes that are independent of Symfony. For that reason, Symfony
doesn't really have an opinion on what tools you use for unit testing.
However, the most popular tools are PhpUnit and PhpSpec.
1.2. Functional Tests
Creating really good functional tests can be tough so some developers
skip these completely. Don't skip the functional tests! By defining some
simple functional tests, you can quickly spot any big errors before you
deploy them:
1.3. Testing JavaScript Functionality
The built-in functional testing client is great, but it can't be used to
test any JavaScript behavior on your pages. If you need to test this,
consider using the Mink or Selenium.
The above text is based on official Symfony documentation found here: http://symfony.com/doc/current/best_practices/tests.html
The above text is based on official Symfony documentation found here: http://symfony.com/doc/current/best_practices/tests.html
2. Acceptance testing
Acceptance testing can be performed by a non-technical person. That
person can be your tester, manager or even client. If you are developing
a web-application (and probably you are) the tester needs nothing more
than a web browser to check that your site works correctly. You can
reproduce a AcceptanceTester's actions in scenarios and run them
automatically after each site change. Codeception keeps tests clean and simple, as if they were recorded from the words of AcceptanceTester.
2.1. Functional vs Acceptance testing
Acceptance tests are front-end only and you are testing
whether you see the correct UI elements. This type of test never
explicitly checks the database with a direct call. Think of it as only
testing what an end-user would be able to see by clicking around in a
browser.
Functional tests are similar to acceptance tests but they do check the database explicitly, something like $I→seeInDatabase() or $I→seeRecord(). Functional tests generally use a DOM parser instead of a browser (or phantomJS) like acceptance tests do – this is why JS is best left to acceptance tests.
Functional tests are similar to acceptance tests but they do check the database explicitly, something like $I→seeInDatabase() or $I→seeRecord(). Functional tests generally use a DOM parser instead of a browser (or phantomJS) like acceptance tests do – this is why JS is best left to acceptance tests.
3. All in one: Codeception
With Codeception you can run unit, functional and acceptance tests..
Why should I use Codeception instead of PHPUnit?
Being the most popular unit testing framework PHPUnit has very limited features for functional testing with Selenium or other backends. Codeception is PHPUnit on steroids. Everything you need for testing is built-in and works just out of the box. No more pain in configuring Selenium, data cleanup, writing XPaths, and fixtures.
Q: It looks just like Behat
Unlike Behat, Codeception tests are written in PHP. Thus, they are more flexible and easy in writing. Also you can use variables and operators, CSS and XPath locators in your tests. These features allow you to build a solid test automation platform for testing your web application. Codeception tests are simple and readable for your developers, managers, and QA team.
Q: We are planning to use Selenium IDE. Why Codeception?
Codeception works great with Selenium. But with Codeception you can write your tests in PHP. The main reason is: Selenium IDE tests are tightly bound to XPath locators. If you ever change anything in layout tests will fall. Codeception locators are more stable. You can use names, labels, button names and CSS to match elements on page. It's much easier to support the Codeception test then Selenium's one. Selenium just can't clean data between tests, can't check database values, or generate code coverage reports.
Q: Is Codeception a tool for testing legacy projects?
Sure you can use Codeception for black-box testing of your legacy application. But in the same manner you can start testing modern web application as well. With modules that integrates with all popular PHP frameworks you can start writing functional tests in seconds. Unit tests? Write them as you do in PHPUnit with some enhancement. Codeception keeps your tests in one place, makes them structured and readable.
Source: http://codeception.com/
Why should I use Codeception instead of PHPUnit?
Being the most popular unit testing framework PHPUnit has very limited features for functional testing with Selenium or other backends. Codeception is PHPUnit on steroids. Everything you need for testing is built-in and works just out of the box. No more pain in configuring Selenium, data cleanup, writing XPaths, and fixtures.
Q: It looks just like Behat
Unlike Behat, Codeception tests are written in PHP. Thus, they are more flexible and easy in writing. Also you can use variables and operators, CSS and XPath locators in your tests. These features allow you to build a solid test automation platform for testing your web application. Codeception tests are simple and readable for your developers, managers, and QA team.
Q: We are planning to use Selenium IDE. Why Codeception?
Codeception works great with Selenium. But with Codeception you can write your tests in PHP. The main reason is: Selenium IDE tests are tightly bound to XPath locators. If you ever change anything in layout tests will fall. Codeception locators are more stable. You can use names, labels, button names and CSS to match elements on page. It's much easier to support the Codeception test then Selenium's one. Selenium just can't clean data between tests, can't check database values, or generate code coverage reports.
Q: Is Codeception a tool for testing legacy projects?
Sure you can use Codeception for black-box testing of your legacy application. But in the same manner you can start testing modern web application as well. With modules that integrates with all popular PHP frameworks you can start writing functional tests in seconds. Unit tests? Write them as you do in PHPUnit with some enhancement. Codeception keeps your tests in one place, makes them structured and readable.
Source: http://codeception.com/
Subscribe to:
Posts (Atom)