Miljar - Tom Van Herreweghe

VIM for IDE people - part 5

Lightweight status line: vim-airline

When editing a file in a plain vanilla VIM instance (simulate this by opening VIM like this: vim -u NORC [file]), there’s not much to see. In fact, there is no information at all about the file you’re editing, except maybe the filename in the window title bar.

Maybe that’s good enough for you. But what if you could have this:

  • Indication of the mode (insert/replace/visual/…)
  • Filename
  • File type
  • File encoding
  • Line & column number
  • Git information
  • Info/error/warning messages
  • …

If you’re thinking “ow yes, that sounds usefull”, then the next part definitely is for you.

What is vim-airline?

Some clever people thought the above sounded like a usefull idea and went ahead and created a plugin for this. The mother of status line implementations is vim-powerline. This project however, is deprecated in favor of powerline.

Powerline is a complete rewrite of the original vim-powerline in Python. If you don’t like Python or are more partial to using VimL, then there’s vim-airline for you.

Vim-airline is a lightweight clone of Powerline, writen in VimL, which has support for color schemes, is completely extendible, has integration for other tools and much much more. Go look at the website if you want the full list.

After installation of vim-airline (see installation instructions), see the help tags (:help airline) for all the configuration options. The ones I used are:

  • let g:airline_theme='solarized' For the solarized theme
  • set laststatus=2 To always display airline (default is only after a split)

That’s right, only 2 configuration options. I’m happy with the default behavior. Try it out, there’s nothing to dislike really…

Read on →

PHPUnit: Testing static calls

When you’re writing code, sometimes it’s necessary to use static calls. Maybe the only way to interface with an external library is through static calls. I must admit, it’s just easy to work with a static call. Until you have to assert in a unit test that you’re actually calling the static method. Then it gets more difficult.

Stubbing and mocking internal static methods

As Sebastian Bergmann explains in one of his blogposts, since PHPUnit 3.5 it’s possible to stub & mock static methods. In the same class. Here’s how it goes.

Sample class with internal static method call
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?php
class Foo
{
  public static function bar()
  {
      // some logic here, and then...
      static::baz($somevar);

      return 'bar';
  }

  public static function baz($somevar)
  {
      // some more logic
  }
}

The unit test goes like this:

Unit test internal static method call
1
2
3
4
5
6
7
8
9
10
11
12
13
14

<?php
class FooTest extends \PHPUnit_Framework_TestCase
{
    public function testBar()
    {
        $class = $this->getMockClass('Foo', array('baz'));

        $class::staticExpects($this->any())
          ->method('baz')
          ->with($this->equalTo('somevar value'));

        $this->assertEquals('bar', $class::bar());
    }
}

So what happens here? The key is that we have 2 static methods, and in the first static method we do a static call to the second static method. All in the same class.

We tell the getMockClass method to give us a mock classname for our Foo class, and we want to stub method baz. Once we have this classname, we can use staticExpects for our expectations.

Then we do our regular static call to the bar method. But instead of doing it on our Foo class, we do it on the mock classname. As such, the mock can use the stub we created when internally static::baz is called.

Stubbing and mocking external static methods

So far that wasn’t too difficult. But how many times have you written code like this? Personally, I don’t ever write code like that. However, sometimes I have to work with an external library and then static calls might be the only available interface.

Sample class with external static method call
1
2
3
4
5
6
7
8
9
10

<?php
class Foo
{
  public function bar()
  {
      // some logic here, and then...

      Log::message('We have just executed Foo::bar()');
  }
}

As you can see, the interface to the Log class makes us use a static call to log a message. Assume that you want to know if you actually do the Log::message call in a unit test, then we’re screwed since the static call is external.

There is a way around that. It’s a hassle and it’s not beautiful. First we have to refactor the external static call a bit:

Sample class with external static method call
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?php
class Foo
{
  protected $loggingClass = 'Log';

  public function bar()
  {
      // some logic here, and then...

      forward_static_call_array(
          array($this->loggingClass, 'message'),
          array('We have just executed Foo::bar()');
      );
  }
}

Instead of calling Log::mesage directly, we use forward_static_call_array. The name of our log class is now defined in a property, and we use that property in the forward_static_call_array method. Can you see where this is going? We’re kind of injecting the Log classname dependency. Not pretty, but it works!

Unit test external static method call
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?php
class FooTest extends \PHPUnit_Framework_TestCase
{
    public function testBar()
    {
      // create a mock class with expectations
        $class = $this->getMockClass('Log', array('message'));
        $class::staticExpects($this->once())
          ->method('message');

      $foo = new Foo();

      // set the mock classname in the property
      $reflProp = new \ReflectionProperty('Foo', 'loggingClass');
      $reflProp->setAccessible(true);
      $reflProp->setValue($foo, $class);

      // call bar()
      $foo->bar();
    }
}

Same as before, we use getMockClass to get a mock classname for the Log class. Then we set this classname in our $loggingClass property. Since it’s a protected property, I can only do that through Reflection. I just made the property protected to make it more difficult ;–).

So here we go, we were able to test an external static method call. It’s up to you to decide if you want to refactor your code like this. And it’s also up to you to decide if you want to actually assert these kinds of calls. I agree, we don’t really want to verify a call to a logger. But that was just an example.

PHPUnit: Testing The Constructor

In a previous blog post I explained how you could mock the system under test. This allows you to easily verify if a given method calls other methods in the same class.

What if you wanted to verify this from the constructor?

Normal classes

Example Car class
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

<?php
class Car
{
  /**
  * @var int
  */
  protected $doors;

  /**
  * Class constructor
  *
  * @return void
  */
  public function __construct($doors = 2)
  {
      $this->setDoors($doors);
  }

  /**
  * Setter for the doors
  *
  * @param int $doors
  * @return void
  */
  public function setDoors($doors)
  {
      $this->doors = $doors;
  }
}

The constructor is a magic function in your class and is invoked when you create a new instance of said class. You don’t explicitly call the constructor method.

Being a meticulous developer and trying to reach 100% unit test coverage, I explicitly want to verify if the constructor calls setDoors. One solution would be the following:

Unit test for the Car class constructor
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

class CarTest extends PHPUnit_Framework_TestCase
{
  public function testConstructorCallsInternalMethods()
  {
      $classname = 'Car';

      // Get mock, without the constructor being called
      $mock = $this->getMockBuilder($classname)
          ->disableOriginalConstructor()
          ->getMock();

      // set expectations for constructor calls
      $mock->expects($this->once())
          ->method('setDoors')
          ->with(
                  $this->equalTo(4)
                );

      // now call the constructor
      $reflectedClass = new ReflectionClass($classname);
      $constructor = $reflectedClass->getConstructor();
      $constructor->invoke($mock, 4);
  }
}

First thing I do, is create a mock object for the Car class, but I request that the constructor is not called with disableOriginalConstructor. Next I set the expectations for my mock object: verify that the setDoors method is called with 4 as an argument. Lastly, through reflection I get a reflection method for the constructor, which I then invoke for the mock object and correct argument.

Abstract classes

For regular classes, the method described above seems straightforward. When dealing with abstract classes, mocking needs some more attention.

PHPUnit provides us with a getMockForAbstractClass method, which conveniently creates a mock for an abstract class. What’s in a name. Now where the regular getMock method doesn’t mock any method unless you specify the ones you want, getMockForAbstractClass by default mocks the abstract methods so you can test the concrete methods.

So far things are logical. If you try the same approach as above for abstract classes, exchanging the ->getMock() for ->getMockForAbstractClass(), you end up with a disappointment. The mock tells you that the internal method wasn’t called. Odd. Doing some var_dump-driven-development tells you that the method is called. However, it’s not reflected in the mock.

How to fix?

Unit test for abstract Car class
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class CarTest extends PHPUnit_Framework_TestCase
{
  public function testConstructorCallsInternalMethods()
  {
      $classname = 'Car';

      // Get mock, without the constructor being called
      $mock = $this->getMockBuilder($classname)
          ->disableOriginalConstructor()
          ->setMethods(array('setDoors'))
          ->getMockForAbstractClass();

      // set expectations for constructor calls
      $mock->expects($this->once())
          ->method('setDoors')
          ->with(
                  $this->equalTo(4)
                );

      // now call the constructor
      $reflectedClass = new ReflectionClass($classname);
      $constructor = $reflectedClass->getConstructor();
      $constructor->invoke($mock, 4);
  }
}

Tadaa! For an abstract class, we explicitly have to define the list of methods we want to stub.

Come to think of it, this is actually logical behavior, as this is how regular mocking works. What’s not logical, is that it works for normal classes without the list of methods you want to stub. So just to be on the safe side (and to have some kind of pattern), just always provide a list of methods. At least, that’s what I’m going to do from now on.

VIM for IDE-people - part 4

Syntax checking: Syntastic

It’s built-in dummy!

A nice thing about an IDE is that it offers visual clues when editing source code files. It’s quite hard to not notice a syntax error in an IDE. The astute Vim adept will immediately tell you syntax highlighting is built-in into Vim. No need for a plugin. And he’s right, Vim comes with a built-in syntax highlighter and even indentation control. You can enable those by adding the following settings to your ~/.vimrc file:

1
2
3
4
5
6

" Takes care of highlight
filetype plugin on
syntax on

" Takes care of indentation
filetype indent on

More on indentation

Indentation can be controlled very granuallary. Here’s an overview of the most commonly used settings:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

" Set an indent to 4 columns
set tabstop=4

" When reindenting, each indentation is 4 columns
set shiftwidth=4

" Don't replace an indentation by 4 spaces
set noexpandtab

" Do replace an indentation by 4 spaces
"set expandtab

" Use 4 columns when hitting Tab in insert mode
set softtabstop=4

If you want more information on indentation and how to control it, I recommend reading Secrets of tabs in Vim.

Syntastic

What we’re after is true language specific syntax checking. For this, we do need a plugin. Enter Syntastic, created by Martin Grenfell, author of NERDTree. What it does, is running your files through external syntax checkers. It then returns those errors and displays them to you. There are syntax checking plugins for a whole bunch of programming languages. Most important for me, is PHP support.

When you write a file and it has syntax errors in it, Syntastic notifies you in a couple of ways:

  1. A mark next to the line where your syntax error is.
  2. When hovering over that marker or line, a balloon with the error messages comes up.
  3. A notification in the status bar. (Never mind that fancy status bar in the screenshot, I’ll talk about it some other time.)

Installation

Quite easy with pathogen:

cd ~/.vim/bundle
git clone https://github.com/scrooloose/syntastic.git

Restart Vim and you’re all set.

Configuration

I’m sorry, everything works out-of-the-box. So there’s no configuration necessary.

PHP Checkers

I’m a PHP guy, and code quality is important to me. Luckily, Syntastic can assist me. There is support for tools like PHPCS and PHPMD. To add these to Syntastic, add this to your ~/.vimrc configuration file:

1

let g:syntastic_php_checkers=['php', 'phpcs', 'phpmd']

Syntastic will first use php lint. If no errors were found, the file is checked with PHPCS for coding standards fails. If there still are no errors, it uses PHPMD for mess detection. If you need help setting up these extra checkers, see :help syntastic-checker-options. Basically, you can override all the arguments for each checker by specifying the arguments in this standardized way: let g:syntastic_<filetype>_<subchecker>_args="<cli args>". Very neat to specify e.g. the coding standards you want your file to adhere to.

Final words

Syntastic comes well configured out-of-the-box. That’s what makes it so easy to use. Once it’s installed, you can just forget about it. If for some reason, you need a checker that’s not available, it should be fairly easy to create your own. Even without much of VimL knowledge. Just read the project wiki and write your missing checker. Don’t forget to share it with the rest of use, right?

Update 22/11/2013 – Corrected some factual errors; Added indentation stuff.

Read on →

VIM for IDE-people - part 3

File system explorer: NERDTree

When working with an IDE, you usually have a way of browsing your local filesystem to choose a file to edit. There’s not such standard functionality built-in into Vim. Luckily there’s The NERD Tree.

NERDTree allows you to browse your file system, open files an directories, and allows simple file operations like creating files/directories, moving them, deleting them, copying them. Everything is presented the way you’re used to: a tree. Hence the name.

Installation

Installation is quite easy with Pathogen, which we installed in Part 1:

cd ~/.vim/bundle
git clone https://github.com/scrooloose/nerdtree.git

Then reload Vim, and NERDTree is available. Display the NERDTree with :NERDTree. This will show you a tree of your filesystem, starting from your current working directory.

Basic commands

When the NERDTree window is active, you can find all available commands by pressing ?. This displays the help. Close the help by pressing ? again. Below is an overview of commands I’m currently using most:

Opening/Closing NERDTree

Just opening NERDTree with the current working directory as root, type :NERDTree.

If you want to open NERDTree with a specific folder as root, type :NERDTree /path/to/folder.

Working with a big screen gives you the option to always have NERDTree open. When your screen real estate is smaller, you can toggle the NERDTree window with :NERDTreeToggle. If you know how to bind a command to a specific key combination, then you can easily switch NERDTree on or off.

Navigation

You can use the regular Vim navigation keys to move around in the tree. With me not being used to the Vim navigation keys, I tend to use the arrow keys. Yes, I know…

Folders

Folders are marked with a triangle in front of them. To open a folder, move to the corresponding line, and press enter. Closing a folder is the same key.

When your cursor is on a file in a folder and you press x, the parent folder closes, placing your cursor on the line of the folder. Repeating x then closes the folder’s parent, and so on.

If your cursor is on a folder, and you want to close all subfolders recursively, hit X (capital x).

Files

After browsing your filesystem, the next thing you’re probably going to is edit a file. To open a file in the last active window, navigate to the correspondig line in the NERDTree panel, and hit enter.

Want to open the file in a new vertical split window? Hit s.

If you’re more of a horizontal split kind of person, hit i to open the file in a new horizontal split.

And finally, if you prefer opening the file in a new tab, hit t.

Using one of these methods above will open the file in your prefered split/tab, and immediately focus in the new split or tab. If you want to just open the file, but keep on navigating your filesystem, you can prefix the split commands with g: gs, gi. This is called a “preview split”. You can do the same with tabs, but then you’d hit T.

Filesystem manipulations

With the NERDTree window active, press m. A menu appears with a list of manipulations available, such as creating a file/folder, moving a file/folder, …

The most important thing to remember is: When you’re creating a folder (m followed by a), don’t forget to add a trailing / to the folder name. If you forget, a file with that name will be created instead of a folder.

Bookmarks

One of the features I like most, is the ability to create bookmarks in your filesystem. A bookmark simply allows you to create a tag for a specific location in NERDTree. Once you have created a bookmark, you can use :NERDTree <bookmark> to have the tree open at this specific location.

Creating a bookmark: Put your cursor on the file or folder you want to bookmark, and type :Bookmark <your bookmark name>

Toggle the bookmark table: B

Delete bookmark: Go to the corresponding line in the bookmark table and hit D.

Final words

NERDTree makes it very easy to browse your filesystem. It should be one of the first plugins you install. Especiall if you come from an IDE, like me, it makes sense to have something available that you know from your IDE world.

One last tip before closing this post: If you’re tired of having to toggle NERDTree each time you fire up Vim, you can have it auto-opened for you. Just put the following in your ~/.vimrc, reload Vim, and it’s there! Beware: it can be annoying if you open Vim in the terminal. Mostly you’re just editing one file, so then the NERDTree window is a bit useless.

1

au VimEnter *  NERDTree
Read on →

VIM for IDE-people - part 2

Color Scheme: Solarized Plugin

Let’s start with an easy one. When working with Netbeans, I had the Solarized color scheme installed. I was really used to this color scheme, and the first thing I did, was install it for Vim.

Installation is quite simple thanks to Pathogen: go to your ~/.vim/bundle folder and git clone git://github.com/altercation/vim-colors-solarized.git

Then edit your ~/.vimrc configuration file. Add the following if you like working with a dark background:

1
2
3

syntax enable
set background=dark
colorscheme solarized

If you like the lighter background, then use this configuration:

1
2
3

syntax enable
set background=light
colorscheme solarized

If you want to reload your ~/.vimrc configuration in your current Vim instance, hit : and type so ~/.vimrc + enter.

Read on →

VIM for IDE-people - part 1

Background

My first encounter with Vim was back in the year 2000, my first year of university. It didn’t really appeal to me. Why on Earth bother with all these keyboard shortcuts when we have a mouse to point with?

Fast forward to 2008, my first PHP conference. The cool kids were all using one or another Linux flavor, and Vim for editing their source code.

We’re 2013 now, and while I’ve been happy editing my source code in Netbeans for the past 8 years, I’m not so happy with it anymore. Time to start learning and using Vim! (MacVim in my case)

First things first: .vimrc

Where to start? I’m an IDE person and some things come with an IDE that don’t come with an off-the-shelf Vim installation. Code completion, highlighting, folding, … Luckily these things can be added to your Vim installation by means of plugins.

Before we start adding plugins, there are some essentials first:

  • I’m not here to tell you how to install Vim. Just google it. I’m using MacVim.
  • Most, if not all, configuration of your Vim editor happens through a file called .vimrc. If it’s not there yet, just create a file with that name in your home folder.
  • Plugins are installed in a special folder in your home folder: ~/.vim/bundle, but more on that later.

Here’s the .vimrc config that I started with. It’s quite basic for now, but I want to learn the basics first, and then gradually extend my knowledge.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

syntax on
filetype plugin indent on

set number          " show line numbers
set lines=60        " make the editor 60 lines tall
set columns=150     " make the editor 150 columns wide

set tabstop=4       " hitting tab produces 4 columns space
set shiftwidth=4    " indent operations produce 4 columns space
set noexpandtab     " don't replace a <tab> with <space>'es
set softtabstop=4   " amount of columns to use when hitting <tab> in insert mode

set history=1000    " keep track of history for 1000 actions

set ruler          " show cursorposition
set cursorline     " highlight current line
set showcmd        " display incomplete commands
set incsearch      " incremental searching
set hlsearch       " highlight searchresult

set scrolloff=4    " keep at least 4 lines above or below the cursor

" fileformat stuff
set fileformats=unix,dos
set encoding=utf-8
set fileencodings=utf-8,ucs-bom,cp1250,iso-8859-1

These settings won’t do anything fancy. Just play with them and see what suits you best.

Plugins

Plugins extend the functionality of Vim far beyond its original capabilities. With the help of Vimscript, almost anything becomes possible with Vim.

The easiest way to install plugins… is with a plugin. Yes, Tim Pope created a plugin, Pathogen, which allows you to install other plugins with almost zero configuration.

For installation of Pathogen, head over to https://github.com/tpope/vim-pathogen and follow the instructions.

Add execute pathogen#infect() on top of your .vimrc, and voila! Now you’re ready to install plugins.

What’s next?

We now have our base Vim configuration: We have a .vimrc file in place that we can add configuration options to. And we are ready to install some plugins.

As I’m learning and using Vim as we speak, I’ll add more blog posts to tell you about my struggles, plugins I’m using and other stuff I’ve learned about Vim.

My goal is to stop using an IDE alltogether, and use Vim for all my source code editing. It won’t be an easy task, but if others can manage it, then so can I. By blogging about my experiences, I hope I can help other people with their struggles.

Update 20/09/2013 It has come to my attention that the examples of supposedly lacking features are actually available right off the bat in Vim. They’re just a bit deeper in the documentation. The things I should have mentioned were: git integration, auto-complete with the tab key, automatically adding closing angles, …

Read on →

PHPUnit: Mocking the System Under Test

When unit testing a class, at one point you’ll have to check if some functionality in a dependency is triggered. Usually this is done by replacing the dependency with a mock object. A well designed system let’s you inject dependencies in your objects, thus allowing for easier unit testing.

Mocking dependencies
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

<?php
class UserService
{
  proteced $mailerService;
  
  public function getMailerService()
  {
      if (empty($this->mailerService)) {
          throw new \RuntimeException('No mailer service set');
      }
      
      return $this->mailerService;
  }
  
  public function setMailerService(MailerInterface $service)
  {
      $this->mailerService = $service;
      
      return $this;
  }
  
  public function registerUser($userObject)
  {
      // …
      
      $mailerService = $this->getMailerService();
      $mailerService->sendMail('registration', $userObject);
  }
}


class UserServiceTest extends PHPUnit_Framework_TestCase
{

  public function testRegisteringUserTriggersMail()
  {
      $userObject = new User('Tom', 'tom@example.com');
  
      $mailerMock = $this->getMock('My\Namespace\MailerService');
      $mailerMock->expects($this->once())
          ->method('sendMail')
          ->with(
              $this->equalTo('registration'),
              $this->equalTo($userObject)
          );
          
      $userService = new UserService();
      $userService->setMailerService($mailerMock);
      
      $userService->registerUser($userObject);
  }

}

The example above tests if the mailer service is triggered when the registerUser() method is called. The System Under Test (SUT) here is the UserService, and the mock object is the MailerService.

But what if you wanted to mock one or more methods in the SUT itself? Like the example below:

Example with internal dependencies
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<?php
class UserService
{
    // ...
  
  public function registerUser($userObject)
  {
      $this->saveUser($userObject);
      
      $mailerService = $this->getMailerService();
      $mailerService->sendMail('registration', $userObject);
  }
  
  public function saveUser($userObject)
  {
      // ...
  }
}

This implementation of the UserService has 2 separate methods: one for saving a User object and a convenience method registerUser which calls saveUser and then sends out a mail.

I’ve sometimes wondered how you can make sure that the registerUser method calls the other method without actually covering the implementation of it. Let me rephrase that: “How can you mock a method in the SUT?”

Of course the answer was quite simple, but it only hit me after a while: Let the SUT become the mock!

In PHPUnit, it’s possible to create a partial mock. That’s a mock with not all its methods mocked. When you invoke a method of a partial mock that wasn’t mocked, then the original method is called. Here’s an example in a unit test:

Mocking the SUT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?php
class UserServiceTest extends PHPUnit_Framework_TestCase
{

  public function testRegisteringUserCallsSaveUserMethod()
  {
      $userObject = new User('Tom', 'tom@example.com');
      
      $mock = $this->getMock('UserService', array('saveUser'));
      $mock->expects($this->once())
          ->method('saveUser')
          ->with($this->equalTo($userObject));
          
      $mock->registerUser($userObject);
  }
}

So first the SUT is mocked, with expectations for our saveUser method. Then on that mock we call the registerUser method, which is not mocked.

If you generate a code coverage report from that test, then only the registerUser method will be covered, which is exactly what I wanted.