Tuesday, February 23, 2016

Save logs to Database and access them from web UI with LexikMonologBrowserBundle

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());

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.

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.
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:

$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:

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

Create the service

In your bundle create a file called services.yml under 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

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.

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/