Robert Basic's blog

Archive for the 'Programming' category

Waste an hour on a stupid mistake

by Robert Basic on April 07, 2017.

I made such a stupid mistake today and lost an hour of my time trying to figure out what the hell is wrong, that I just have to blog it.

I was working on embedding a Symfony form into another form, following the documentation to the letter… Yet there I was staring at this stupid error message:

The options "0", "1" do not exist. Defined options are: "action", "allow_add", "allow_delete",
"allow_extra_fields", "attr", "auto_initialize", "block_name", "by_reference", "compound",
"constraints", "csrf_field_name", "csrf_message", "csrf_protection", "csrf_token_id",
"csrf_token_manager", "data", "data_class", "delete_empty", "disabled", "empty_data",
"entry_options", "entry_type", "error_bubbling", "error_mapping", "extra_fields_message",
"help", "inherit_data", "invalid_message", "invalid_message_parameters", "label", "label_attr",
"label_format", "mapped", "method", "post_max_size_message", "property_path", "prototype",
"prototype_data", "prototype_name", "required", "translation_domain", "trim",
"upload_max_size_message", "validation_groups".

What the hell…

Excerpt of the code that was throwing the error:

<?php
declare(strict_types=1);

namespace AppBundle\Form;

use AppBundle\Form\SampleType;
use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\Extension\Core\Type\CollectionType;
use Symfony\Component\Form\FormBuilderInterface;
use Symfony\Component\OptionsResolver\OptionsResolver;

class MultiSampleType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder
            ->add('samples', CollectionType::class, [
                'entry_type', SampleType::class,
                'allow_add' => true,
            ]);
    }

    public function configureOptions(OptionsResolver $resolver)
    {
        $resolver->setDefaults(array(
            'data_class' => null,
        ));
    }
}

I read the documentation over and over again, searched for any one else coming up with the same error, went through the issues on the Symfony repositories… Nothing.

Now when I look at this code sample the error is poking my eyes out, but this morning when I was looking for it… Crickets.

Let’s “zoom” in:

<?php
->add('samples', CollectionType::class, [
    'entry_type', SampleType::class,
    'allow_add' => true,
]);

Do you see it?

The error is that the entry_type should be a key, instead of a value, and SampleType::class is the value for the entry_type key.

<?php
->add('samples', CollectionType::class, [
    'entry_type' => SampleType::class,
    'allow_add' => true,
]);

So stupid.

Oh well, I guess this also part of programming.

Happy hackin’!

Tags: php, stupid.
Categories: Blablabla, Development, Programming.

PHP traits to create test doubles

by Robert Basic on April 04, 2017.

Keeping your application or library code well organized, easy to follow, and read is important. Your test code should not be exempt from those rules, you should follow good testing conventions.

One part of my tests that I feel like that are out of control are the test doubles. Dummies, fakes, mocks… Seems like they are everywhere and that I keep writing the same ones over and over again.

I do follow some good practices on how to reduce code duplication in my tests, but these mocks…

Ugh.

Test doubles are everywhere

Lets look at a couple of example test cases:

tests/App/UnitTest/Transaction/TransactionTest.php

<?php declare(strict_types=1);
namespace App\UnitTest\Transaction;

use PHPUnit\Framework\TestCase;
use App\Account\Account;
use App\Account\AccountType;
use App\Transaction\Transaction;

class TransactionTest extends TestCase
{
    protected $asset;
    protected $expense;

    public function setup()
    {
        $this->asset = new Account(new AccountType('asset'), 'Cash');
        $this->expense = new Account(new AccountType('expense'), 'Groceries');
    }

    public function testTransactionCanBeExecutedBetweenAssetAndExpenseAccounts()
    {
        $transaction = new Transaction($this->asset, $this->expense, '5', 'EUR');

        $result = $transaction->execute();

        self::assertTrue($result);
    }

    public function testTransactionCannotBeExecutedBetweenExpenseAndAssetAccounts()
    {
        $transaction = new Transaction($this->expense, $this->asset, '5', 'EUR');

        $result = $transaction->execute();

        self::assertFalse($result);
    }
}

It’s not so bad, right? We create a couple of account types, so we can create a couple of account objects which are then used to test can a transaction be executed or not.

And then we need to test the persistence of the transaction in another test case. Again we create a couple of account types, accounts, create a transaction…

And then we need to test the TransactionExecuted event. Account types, accounts, transaction…

Over and over again.

Traits to the rescue

What if we move the creation of those test doubles to traits?

A trait for creating account types:

tests/Traits/AccountTypeTrait.php

<?php declare(strict_types=1);
namespace Traits;

use App\Account\AccountType;

trait AccountTypeTrait
{
    public function fakeAssetAccountType() : AccountType
    {
        return new AccountType('asset');
    }

    public function fakeExpenseAccountType() : AccountType
    {
        return new AccountType('expense');
    }
}

and a trait for creating accounts:

tests/Traits/AccountTrait.php

<?php declare(strict_types=1);
namespace Traits;

use App\Account\Account;
use Traits\AccountTypeTrait;

trait AccountTrait
{
    use AccountTypeTrait;

    public function fakeAssetAccount() : Account
    {
        return new Account($this->fakeAssetAccountType());
    }

    public function fakeExpenseAccount() : Account
    {
        return new Account($this->fakeExpenseAccountType());
    }
}

The example test case from the beginning now becomes a little bit more clear, hopefully:

tests/App/UnitTest/Transaction/TransactionTest.php

<?php declare(strict_types=1);
namespace App\UnitTest\Transaction;

use PHPUnit\Framework\TestCase;
use App\Transaction\Transaction;
use Traits\AccountTrait;

class TransactionTest extends TestCase
{
    use AccountTrait;

    public function testTransactionCanBeExecutedBetweenAssetAndExpenseAccounts()
    {
        $transaction = new Transaction($this->fakeAssetAccount(), $this->fakeExpenseAccount(), '5', 'EUR');

        $result = $transaction->execute();

        self::assertTrue($result);
    }

    public function testTransactionCannotBeExecutedBetweenExpenseAndAssetAccounts()
    {
        $transaction = new Transaction($this->fakeExpenseAccount(), $this->fakeAssetAccount(), '5', 'EUR');

        $result = $transaction->execute();

        self::assertFalse($result);
    }
}

A trait for every test double, clearly named as to what they create. fakeAssetAccount, mockTransactionRepository. Each test double can now be reused more easily across different test cases, if for some reason they need to be changed, we change them only in one place.

Just need to be disciplined on the naming of the traits and the methods they provide.

Currently I see no pitfalls with this approach, but time will tell is this a good idea or not.

Happy hackin’!

Tags: mocks, php, phpunit, tdd, test doubles, testing, traits, unit testing.
Categories: Development, Programming.

Loading fixtures for a Symfony app in Behat tests

by Robert Basic on March 21, 2017.

Performing end to end testing of any application requires from us to have a set of reliable test data in the database.

If we write a Symfony application and use Behat to do the end to end testing, the we can use the Doctrine fixtures bundle to create the required fixture loaders and load them in our Behat scenarios when required, using the BeforeScenario hook.

Install Doctrine fixtures bundle

Using composer we can install the Doctrine fixtures bundle:

composer require --dev doctrine/doctrine-fixtures-bundle:2.3.0

and enable the bundle in the AppKernel:

app/AppKernel.php

diff --git a/app/AppKernel.php b/app/AppKernel.php
index 0d22098..c30e863 100644
--- a/app/AppKernel.php
+++ b/app/AppKernel.php
@@ -27,6 +27,7 @@ class AppKernel extends Kernel
             $bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
             $bundles[] = new Sensio\Bundle\DistributionBundle\SensioDistributionBundle();
             $bundles[] = new Sensio\Bundle\GeneratorBundle\SensioGeneratorBundle();
+            $bundles[] = new Doctrine\Bundle\FixturesBundle\DoctrineFixturesBundle();
         }

         return $bundles;

Write a fixture loader

Now we can write a fixture loader. Writing fixture loaders is explained well in the official documentation.

Here’s an example fixture loader for the FOSUser bundle, creating users for the application:

src/AppBundle/DataFixtures/ORM/LoadUserData.php

<?php

namespace AppBundle\DataFixtures\ORM;

use Doctrine\Common\DataFixtures\FixtureInterface;
use Doctrine\Common\Persistence\ObjectManager;
use Symfony\Component\DependencyInjection\ContainerAwareInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;

class LoadUserData implements FixtureInterface, ContainerAwareInterface
{
    /**
     * @var ContainerInterface
     */
    private $container;

    public function setContainer(ContainerInterface $container = null)
    {
        $this->container = $container;
    }

    public function load(ObjectManager $manager)
    {
        foreach ($this->getData() as $data) {
            $userManager = $this->container->get('fos_user.user_manager');

            $user = $userManager->createUser();

            $user->setUsername($data['username']);
            $user->setUsernameCanonical($data['username']);
            $user->setPlainPassword($data['password']);

            $user->setEmail($data['email']);
            $user->setEmailCanonical($data['email']);

            $user->addRole($data['role']);
            $user->setEnabled($data['enabled']);

            $userManager->updateUser($user, true);
        }
    }

    private function getData()
    {
        return [
            [
                'username' => 'admin',
                'password' => 'adminpassword',
                'email' => 'admin@email.com',
                'firstname' => 'Boss',
                'lastname' => 'Big',
                'role' => 'ROLE_ADMIN',
                'enabled' => true,
            ],
        ];
    }
}

Do note that the LoadUserData fixture loader also implements the ContainerAwareInterface, meaning that it will get an instance of the ContainertInterface when invoked through the bin/console doctrine:fixtures:load console command.

We use this instance of the container to get the user manager from the FOSUser bundle. In turn, we use the user manager to create and update the users we are loading with this fixture loader.

Rest of it is straightforward — we set the username, email, password, role on the user and update it. The user manager will handle the password encryption as per the application configuration, saving the user to the database, and so on…

Load fixtures in Behat tests

The Behat test file has a bit more to it.

It requires the Behat Symfony2 extension (so far it works for Symfony 3 applications as well!)

composer require --dev behat/symfony2-extension:2.1.1

Next, we need to tell Behat to pass an instance of the AppKernel to our test. We do so through the behat.yml file:

behat.yml

default:
    suites:
        my_feature:
            contexts:
                - 'FeatureContext':
                    kernel: '@kernel'
    extensions:
        Behat\Symfony2Extension:
            kernel:
                class: AppKernel

This will allow our FeatureContext test file to get an instance of a KernelInterface, the AppKernel, through the constructor:

features/bootstrap/FeatureContext.php

<?php

use Doctrine\ORM\Tools\SchemaTool;
use Symfony\Component\HttpKernel\KernelInterface;
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;

use AppBundle\DataFixtures\ORM\LoadUserData;
use Behat\Behat\Hook\Scope\BeforeScenarioScope;
use Doctrine\Common\DataFixtures\Executor\ORMExecutor;
use Doctrine\Common\DataFixtures\Loader;
use Doctrine\Common\DataFixtures\Purger\ORMPurger;


class FeatureContext
{
    protected $container;

    protected $entityManager;

    public function __construct(KernelInterface $kernel)
    {
        $this->container = $kernel->getContainer();

        $this->entityManager = $this->container->get('doctrine.orm.default_entity_manager');

        $schemaTool = new SchemaTool($this->entityManager);
        $schemaTool->dropDatabase();
        $metadata = $this->entityManager->getMetadataFactory()->getAllMetadata();
        $schemaTool->createSchema($metadata);
    }
}

We get the container from the kernel and the entity manager from the container. No need to setup anything, it’s all taken care of under the hood.

We also use this “occasion” to make sure that the database schema is recreated before the test is ran.

The final step is to load the fixtures data we need in our FeatureContext.php test file:

    /**
     * @BeforeScenario
     */
    public function loadDataFixtures(BeforeScenarioScope $scope)
    {
        $userData = new LoadUserData();
        $userData->setContainer($this->container);

        $loader = new Loader();
        $loader->addFixture($userData);

        $purger = new ORMPurger();
        $purger->setPurgeMode(ORMPurger::PURGE_MODE_DELETE);

        $executor = new ORMExecutor($this->entityManager, $purger);
        $executor->execute($loader->getFixtures());
    }

The main thing to note here is that the container is not automatically set on the LoadUserData fixture loader, so we need to do that manually by calling the setContainer method with $this->container as an argument. Remember, we got the container instance from the kernel in the class constructor.

We tell the loader which fixture to load, the purger to delete any existing records from the database and finally the executor to load our fixtures.

Now when we run the Behat test suite, the database, in the environment against which we run the tests, will have a fresh set of data every time.

Happy hackin’!

Tags: behat, fixtures, php, symfony.
Categories: Development, Programming.

Current Vim setup for PHP development

by Robert Basic on February 10, 2017.

I made some changes to my Vim setup for PHP development recently, so it’s time to write it all down. I’m more than sure that I’ll break it soon and won’t be able to remember all the things I did to have the current setup.

Some new plugins popped up on my radar, I tweaked some older plugins and I even wrote one for PHPStan!

Last year I wrote how I got really good tag support in Vim, so I’ll first expand on that.

Gutentags

Gutentags is probably the plugin that had the biggest impact on my workflow. It made possible many other functionalities and plugins to just work.

First thing I have configured for it is the location for the tag files:

" Where to store tag files
let g:gutentags_cache_dir = '~/.vim/gutentags'

The second is a more “aggressive” excluding of files from generating tags:

let g:gutentags_exclude = ['*.css', '*.html', '*.js', '*.json', '*.xml',
                            \ '*.phar', '*.ini', '*.rst', '*.md',
                            \ '*vendor/*/test*', '*vendor/*/Test*',
                            \ '*vendor/*/fixture*', '*vendor/*/Fixture*',
                            \ '*var/cache*', '*var/log*']

Takes out a lot of rubbish.

I also have the following in the global ~/.ctags configuration file (gutentags uses ctags under the hood to generate the tags):

--PHP-kinds=+cfit-va

This way I get tags for classes, interfaces, functions, namespaces and traits, while variables and aliases are ignored to remove the noise level.

Jump to definition

I paired CtrlP’s CtrlPTag method with gutentags tag files to get jump to definition functionality:

map <silent> <leader>jd :CtrlPTag<cr><C-\>w

My complete CtrlP settings are here.

Current PHP class and method

A combination of three Vim plugins and a PHP phar file gives me the possibility to show in the status bar the current PHP class and method.

Lightline provides the status bar, tagbar to get the current tag, tagbar-phpctags to generate the tags for the current file using phpctags.

Use the following setting to tell tagbar about the phpctags binary:

let g:tagbar_phpctags_bin='~/.vim/phpctags'

This is the tagbar line for lightline:

'tagbar': '%{tagbar#currenttag("[%s]", "", "f")}',

See here how it all fits together.

Now that I wrote it all down, I should take a look if I could use the gutentags tag files for this. Seems like an awful lot of moving parts for a relatively small feature.

PHP namespaces

The vim-php-namespace plugin provides support for inserting use statements in PHP code. It will use the tag files generated by gutentags, there’s no need to set up anything for that.

I have the following mapping to insert the use statements:

function! IPhpInsertUse()
    call PhpInsertUse()
    call feedkeys('a',  'n')
endfunction
autocmd FileType php inoremap <Leader>pnu <Esc>:call IPhpInsertUse()<CR>
autocmd FileType php noremap <Leader>pnu :call PhpInsertUse()<CR>

and this one for expanding classes to get their fully qualified names:

function! IPhpExpandClass()
    call PhpExpandClass()
    call feedkeys('a', 'n')
endfunction
autocmd FileType php inoremap <Leader>pne <Esc>:call IPhpExpandClass()<CR>
autocmd FileType php noremap <Leader>pne :call PhpExpandClass()<CR>

I also let it to automatically sort the namespaces after inserting:

let g:php_namespace_sort_after_insert=1

Linting

ALE is an Asynchronous Lint Engine and it provides linting for Vim 8. It can do linting for a bunch of languages.

My configuration for it is:

let g:ale_linters = {
\   'php': ['php'],
\}
let g:ale_lint_on_save = 1
let g:ale_lint_on_text_changed = 0

Lints PHP files on save, in the background. A must have!

A promising completion engine for PHP

php.cd finally provides useful completion for PHP. It’s still rough around the edges, misses a feature or two, but I find it a lot better than any other completion engine I used before. No need to configure anything for it, just follow their installation instructions and that’s it. ^X^O all the things!

PHPStan in Vim

PHPStan is a static analysis tool for PHP and I wrote a small plugin for it, vim-phpstan. It calls phpstan from Vim and populates Vim’s quickfix list with the errors.

For now, the only possible configuration is to set the analyse level:

let g:phpstan_analyse_level = 2

Debugging

Sadly, there is no good PHP debugging client for Vim. Or none that I know of. There are a couple of them out there, but they seem long abandoned. I work on a standalone PHP debugging client, pugdebug, but it has it’s own set of problems as well (packaging on Linux is a nightmare).

Supporting plugins

Other “supporting” plugins are 2072/PHP-Indenting-for-VIm, 2072/vim-syntax-for-PHP, sirver/ultisnips, plugins from the sniphpets organization, ddrscott/vim-side-search, robertbasic/vim-argument-swapper.

I’m pretty happy with the current setup. Do you know maybe of any interesting plugin I’m missing? Let me know!

Happy hackin’!

Tags: ale, completion, gutentags, linting, namespaces, php, phpcd, phpctags, phpstan, plugins, tagbar, vim.
Categories: Development, Programming.

Things I learned in the past four years

by Robert Basic on December 30, 2016.

Since yesterday was my last day on a project after four years and two months, I decided to take a look back on those four years and write down some of the things I learned.

Things I learned about being a better listener, a better communicator, a better team mate, a better programmer.

Leave your ego at the door

This is probably one of the hardest and most important lessons I learned. I’m happy that I learned it early into the project.

Ego gets into the way of the actual programming. There is no place for it. People get defensive about their code, become deaf to advice, don’t take criticism well. This slows down the development process, makes communicating difficult, if not impossible.

Criticism of my code is not criticism of me. If I submit a pull request and the reviewer deems the code not fit for inclusion into the project, there is nothing to get upset about. The code needs improvement. If I know how, I’ll improve it, if not, I’ll ask for help how. It is much better and efficient than getting all protective about the code.

Don’t play the blame game

Joe wrote an excellent piece on the blame game more than 3 years ago.

Removing the blame from the entire process is liberating. When dealing with a problem, don’t focus on trying to find the person, or persons, responsible for the issue at hand, but try to understand what caused the problem, what is the best and fastest way to solve it, and how to prevent it from happening again in the future.

I know I was lucky to be working on a project where this blame game was not being played and that there are a lot of teams and companies where there’s a ton of office politics and everyone wants to survive… But that stuff really isn’t helping any one. If possible, at least try to not play it within your team, with your closest coworkers.

Take responsibility

Admitting to a mistake is hard. It’s scary.

Admitting first to myself that I’m not infallible, that mistakes happen makes taking responsibility a lot easier. And it becomes easier over time.

I believe that people tend to react positively to sincerity. Being honest and upfront that I made a mistake, saying sorry, goes a long way. Yes, the mistake might have repercussions, but I’m an adult and I stand by what I did.

Taking responsibility is the professional thing to do.

It’s OK to say I don’t know

I don’t know.

I’ve said it a lot. I’m still here, still alive, the world didn’t come to an end. No one punished me for it. The only thing that happened is that I learned new things I didn’t know before. And guess what? Learning new things is part of the job.

Saying “I don’t know, can you show me please?” is perfectly fine. If we ask for help, we will get it. People like helping.

Knowing the business domain is important

We, programmers, are a smart bunch of people. We solve problems for a living. Without knowing what is the actual problem the business is trying to solve and just waiting for others to give us a solution which we need to translate into code, takes away the problem solving for which we initially signed up for. The business will also miss out on properly utilizing the experience we gained so far.

Understanding the core domain makes it possible to give ideas, work together with other people (not necessarily programmers) to come up with better solutions. Everyone will benefit from this. The business gains by having yet another smart person helping out, and you by learning new things.

Not everything we learn need to be exclusively about code.

Ask why?

This goes hand in hand with knowing the business domain.

Keep asking why. Why is some new feature being implemented, why do they need it? If you are joining a project that is being developed for some time, ask why were some things done in a certain way. It will both make learning the business domain easier and faster and it will also help with getting to know the codebase.

Asking why shows the business owners that you care, and caring about the same things as they do will only be helpful during the project’s lifetime. They will provide help and explanations much easier.

Onto new adventures

Working on this huge project for this long is something I’m truly grateful for. Not everyone gets an opportunity like this, especially this early in their professional career.

I learned a lot from my friend, partner and mentor, Srdjan, as well as from Luka who joined our small team recently.

I’m certain the new year will bring us exciting new challenges. If you have, or know of a project where the three of us could help out, let us know.

The Code4Hire team is here to help.

Tags: about, learning, me, random.
Categories: Blablabla, Development, Programming.