Code coverage – it’s not good for you

When I see people trying to embrace the concept of BDD, most of the time they will try to apply on it everything that they’ve learned in TDD.  Remember though that BDD is in fact TDD but done right – so stop dragging along all the bad habbits that BDD is trying the leave behind. The most common case pointed out is the lack of code coverage and tools for reporting it. If you are one of those people I’ve got bad news for you – code coverage is not a good metric.

Clean cut test hero

So why is it so bad and why is there no value added with those code coverage reports? You might argue that as a developer you feel very safe and secure when every line of code is tested and you have your CI environment to prove that. Stop! If you’re feeling insecure about the code without your coverage reports – that means you didn’t write it good. It may have as many tests as you want but ask yourself those 3 questions:

• Does it do what I expect it to do?
• Do I know what is it expected to do? - oh legacy… 
• Do I feel confident changing something that gazillion regression tests prove is ok?

Oh coverage, guide my path

I hope you can see the problem here. The issue is that TDD has started being done wrong (some people do it right!) and in most cases the tests are very code-focused (duh!). What I mean is that developers tend to put their effor in writting tests about how the internals of functions work or how this data structure looks like etc. This is a dead end. I’ve seen dozens of tests just testing setters and getters and a bunch of redundant stuff. You might’ve seen that as well and I think by this point you know why. Obviously they are just an attempt to satisfy the gods of code coverage.

How can you have any pudding if you don’t eat your meat?

The feeling I’ve got is that TDD has gotten very code-centric instead of client-centric and it has drifted strongly from it’s best practices. It’s has become a domain of people who are more about code coverage reports, building over-complicated architecture and verifying stuff instead of focusing to deliver software that does what is expected, is self-explanatory and has clear rules of communicating with other software. Most often tests are so tightly checking the code itself that it disables refactoring. BDD is about the code being flexible and understanding that it changes overtime – this is a living organism. The only thing is to maintain it to do what expected and allow it to refactor itself for example according to the boy scout rule.

Don’t worry be happy

What BDD does to you is that it makes you think about what your software delivers. What story does it tell ? What have you specified it to do and what examples have you given ? In that approach you don’t need any coverage report. You’ve written a code that does what you expect it to do – moreover you have the freedom and flexibility of refactoring it. Believe me when I say I sleep better at night knowing that my code does what it should do and not carrying about the percentage of my code coverage.

DISCLAIMER: The problem described below has been fixed by the mocking framework Prophecy. Thank @_md and @everzet on Twitter.

Lately I’m doing some quite extensive specing with PHPSpec. Of course when you do BDD or TDD you always have to mock your dependencies. Mocks can be very effective but they have a serious flaw which can leave your code in bad state. Working the other day on some specs with a colleague of mine we’ve runned into a curious situation. When you do a lot of mocking you can accidentally mock methods that don’t exist and even forget about implementing them. Obviously the specs will run as expected so you won’t even know that the code doesn’t work.

This is a common problem for PHPSpec and PHPUnit (issue) as well. So without further ado

The example

// spec for classA
...
$classBCollection = array(...);
$mock->beAMockOf('\ClassBRetriever');
$mock->getClassBBySomeCriteria(ANY_ARGUMENTS)
    ->willReturn($classBCollection);
$this->setClassBRetriever($mock);
...
$this->someMethodThatUsesClassBRetriever()->will ...

The problem

As you can see the mock has getClassBBySomeCriteria method behavior defined and since it could not even exist – everything is fine at the moment of executing tests or specs. Normally you wouldn’t have specs/tests for that method because it only retrieves data from the database which is not supposed to be specified or tested.

It gets complicated when you actually try to run the implementation. You’ll notice that you haven’t really implemented the method so the code breaks. Furthermore if you did implement the method and somebody has removed or renamed it then you won’t even notice that fact when running your specs/tests. Another problem is that when you make changes you would have to go through your whole specs or tests in order to fix the mocks.

One thing that could fix it would be if the mocks displayed some kind of warning in the console. For example “Hey you are mocking a method that does not exist!”. I’ve raised an issue for that in PHPSpec and as it turns out it is already a work in progress. So you have to hold your breath for that one.

The approach

Since this is not implemented yet the thing you could do is to mock interfaces. This is not a perfect solution but it ensures that you have to implement all abstract methods in classes that implement the interfaces. Another thing is that you will most certainly end up with a better, more loosely coupled design. Then again you have to mock methods that are in the interface as well – so again you have to be very aware of what you’re mocking. As I said this is not the perfect solution for the whole scope of the problem but it works for most of the aspects.

Lately I’m writting a REST API and since I have converted fully to BDD there is nothing better then Behat to describe my features for the API. So having that said I noticed that there is some serious memory leaking when you use Propel 1.6 with Behat. All the scenarios are executed in one process and because of that Propel becomes a real memory hog. Apparently Doctrine can have the same problems.

I’ve tried closing the connections after the scenarios but that actually was not the case (Propel handles it pretty nicely). The problem turned out to be pretty simple. Propel keeps already retrieved objects in it’s cache called Propel Instance Pool. So after each feature/scenario the pool might be getting bigger because it still runs in one process. The solution is very straight forward:

use Behat\MinkExtension\Context\MinkContext;
use Behat\Behat\Event\SuiteEvent;
use Propel;

/**
 * Features context.
 */
 class FeatureContext extends MinkContext
 {

    /**
     * @BeforeSuite
     */
    public static function prepare(SuiteEvent $event)
    {
        Propel::disableInstancePooling();
    }

    // ...

You have to define a before suite hook in your feature context where you will disable the instance pool and that’s it. Hope it helps

Probably like most of you reading this post I’m a PHP developer that was deeply into TDD. Some time ago I’ve felt in love with the BDD concept and a tool called Behat. My work made sense on the level that I’ve finally was able to get in the software’s beneficient role. Behat gave me an awesome tool for describing my software’s specifications and as a bonus I had the functional tests for it. But there was still something missing. I mean I was still hooked into doing TDD with PHPUnit so I lacked unit tests obviously in BDD.

And then there came PHPSpec2…

I’m trully enjoying the concept of SpecBDD with PHPSpec2 nowadays. Don’t get me wrong – I’ve enjoyed PHPUnit over the years but I think there is a new king coming. This is a game changer if you’ve been into TDD like me before. BDD is advertised most of the time as TDD done right, and ofcourse you might have done it right, but there are some pitfalls in which we all fall if we’ve got the wrong tools for it.

PHPSpec2 may be in it’s really early alpha days now but I can see it already as a great tool that helps me to do things right. I’m very pleased with the way how it is descriptive and intuitive in usage. For example when you specify a class and see something like this:

public function let($mailer)
{
    $mailer->beAMockOf('\Swift_Mailer');
    $this->beConstructedWith($mailer);
}

Try to read it in one sentence out loud: “Let mailer be a mock of swift mailer and this be constructed with mailer”. This is sooo intuitive when you look at someone else’s specs. This is just the way you would say it to a friend. And that’s the best thing about PHPSpec – it’s your friend.

Focus on the behavior

I think the most powerfull thing about PHPSpec is that when you describe your classes you’re not deep down into how the functions work but you sure as hell are buletproofing the architectural design and ofcourse the outcome. For example if you specify a class and make good prophet objects for it’s dependencies you will end up with having nice loosely coupled classes.

I’ve seen a lot of people asking about “how can I specify a class with PHPSpec that looks like that …”. I always look at those examples and ask myself if I would write a class like that if I’ve written the specs first. The answer is obviously NO! So my advice to you is forget about what the functions do – think about what you want the class to do. Think about the behavior. Write your specs and you’ll see that you will refactor the class and benefit from it big time.

Don’t test – spec and THINK !

Another thing is that PHPSpec makes you THINK ! I have many times struggled with it to achieve some goal and almost every time ended up with an “Hey! My class is not suppose to do that anyway. This was stupid in the first place”. Almost in all cases I’ve always changed it to the proper simple specification and example schema and it was always spot on! I’ve delivered the software that does exactly what I want it to do.

BDD is for you and me

Nowadays I can feel that my developer’s toolbelt is finally complete. I’m throwing away the old rusty hammers and screwdrivers and have my new shiny toys – Behat for StoryBDD and PHPSpec for SpecBDD. For sure I will be evangelising BDD wherever or whenever I meet any fellow developers.

What I was thinking for some time now was writting my own Symfony 2 Bundle. I had some ideas what I want to do and one of them was to implement the Last.fm API. I found a bundle for that but it was written in a messy way and there were only methods concerning albums. On top of that it had very poor test coverage. Then there was KnpLabs’ php-lastfm-client, but it was not a Symfony 2 bundle. You might say “Hey but you can wrap that in a bundle easily !” – Yes, I could but first of all were’s the fun in that and secondly I wanted to have a solution that would help you to get there without actually reading and analysing the Last.fm API.

So as I thought I did. I made the bundle project available on github and encouraged actually anyone on Twitter that would like to participate with me:

I'm working on a #Symfony2 #Lastfm #API Bundle. Feel free to join in if you like :) https://t.co/wgjbJMnR #PHP

August 21, 2012 11:33 am via TweetDeckReplyRetweetFavorite

@karolsojko

Karol Sójko

Then I’ve created some issues and milestones so anyone would know where to start  :

Created some new issues if somebody wants to help with BinaryThinkingLastfmBundle for #Symfony2 https://t.co/KumZTgZY

August 29, 2012 9:39 pm via webReplyRetweetFavorite

@karolsojko

Karol Sójko

The bundle is available on :

• github
• KnpBundles
• packagist
• Travis CI

The installation instructions are available @ github so feel free to install it, run the tests and start helping . At this moment I have Artis and Album contexts covered – check the milestones to see where it is going now . Give me a shout on twitter @karolsojko if you like it

Selecting records to remove

The issue with big data tables is that you can’t easily perform simple queries like deleting a couple of records without exceeding either time or memory. You can encounter those problems both on MySQL side or PHP/Apache side.

If there are a lot of records involved, you will want to push the whole data processing to the MySQL side. For example in my case I wanted to add a missing foreign key and I wanted to select the records that had missing foreign references in order to delete them.

When I started with something like this :

SELECT a.id FROM table_A a WHERE a.bid NOT IN
(SELECT b.id FROM table_B b);

This was very stressful for the database engine because it gave the tables a full scan. So I quickly went from that to:

SELECT a.id FROM table_A LEFT JOIN table_B b
ON a.bid = b.id WHERE b.id IS NULL;

The Procedure

Now this was much faster. But I still wanted to move the weight of this to MySQL because I knew PHP didn’t have the capacity to handle such amount of data.

The way to go was to create a procedure for MySQL and then call it from PHP. What I came up in the end was something like this:

CREATE PROCEDURE deleteMissingKeyRecords()
BEGIN
  DECLARE done INT DEFAULT FALSE;
  DECLARE aId INT;
  DECLARE aCursor CURSOR FOR
    SELECT a.id FROM table_A LEFT JOIN table_B b
    ON a.bid = b.id WHERE b.id IS NULL;
  DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;

  DECLARE EXIT HANDLER FOR SQLEXCEPTION ROLLBACK;
  DECLARE EXIT HANDLER FOR SQLWARNING ROLLBACK;

  START TRANSACTION;

  OPEN aCursor;

  read_loop: LOOP
    FETCH aCursor INTO aId;
    IF done THEN
      LEAVE read_loop;
    END IF;
    DELETE FROM tableA WHERE id = aId;
  END LOOP;

  CLOSE aCursor;

  COMMIT;
END;

Now this is probably the most effective way to delete records from big data tables. Now the only thing you want to do is :

CALL deleteMissingKeyRecords();

The environment tune

If you have a fairly big amount of data you could expect errors like this one :

ERROR 1206 (HY000): The total number of locks exceeds the lock table size

Now during the delete operation the table is locked and you could exceed your environment’s limit of locks if a lot of data is being deleted. The solution here is to change in your MySQL configuration (which you can find at /etc/my.cnf or /etc/mysql/my.cnf) the InnoDB buffer pool size. I came across this solution on Cowboy Coded blog

Go to the configuration file and add:

innodb_buffer_pool_size = 1G

Please adjust respectivly if the errors still occure. When the procedure is executing you can just show the processlist on MySQL – if it’s not preparing then it should say what records are being deleted now. Leave a comment if it helped you

When introducing test driven development to programmers that don’t have a good grip of it and don’t really feel the need to wite tests, there are a couple of things that you should keep in mind. Here are some ideas that helped me change my friends minds from “just do it” to “test first” approach.

Prepare the environment

First of all make sure you got the environment properly set up in your project so it’s good to go. Don’t bother people that are just eager to learn about tests with setting up stuff. They just want to go straight to the bussiness. Make sure you don’t trouble them on “how & why” it works at first. Ofcourse you will be showing them that later on, but don’t focus on that at the starting point. You can easily discourage people that have their best intentions to try something new – and believe me, most of the time they do.

Make some tests

Just like the point above – make some starting point tests to show them how it works. Write some simple example tests to make it easier for you to explain the idea of TDD. Make sure you have some functionality implemented for some of the tests to pass and some of them to fail.

Design the function

In this moment I think it is very important to work in pairs. Sit down and design the function toghether. Explain how crucial it is to think of the input and output when designing a function and writting a test. This is the part when you plan how it works. When you’ve got a failing test move on to the implementation. Now this is the part that is the most satisfying for developers. Crossing the bridge between a failing test and a nicely green passed test.

Explain the bright side

When you’ve got the feeling that people think there is something curiosly satisfying in writting tests try to explain more and more positives about TDD. Mention that this is the way the code is cleaner because it is designed properly first. When you’re at that make them feel secure by showing that once they’ve written a piece of code and it is covered by tests properly then they can be sure that no one will change the functionality without breaking the tests. This is very welcomed in environments where there are many developers that work on one project.

Show failures

When an opportunity strikes change some functionality the way it is ment to be changed but in a way that it breaks the tests. This will make people who have written it and the tests fight like lions for fixing the code and tests to have it nice and neet once more. Even better when they put pressure on you to fix it. This is the part in which you know you’ve got them hooked on TDD.

I hope that the series of “Preparing for PHP ZCE exam” helped you to learn for the exam itself . As for me I have successfully passed the exam on 25th of April 2012. This is just a short note that I would like to share with all people reading my series of articles.

The exam had it’s difficult parts and some tricky one’s as well but a fair part of them were easy for someone who has prepared for it. I strongly advise you to focus on some of the parts that I’ve mentioned are worth learning and I hope you should pass you exam as well. Please don’t ask me about the exam’s questions as I am legally bound not to give them. Once more I wish you all good luck and passing the exam

This is one of the easy chapters that everyone should be well familiar with. So just refresh your memory on this one because it may earn you some easy extra points in the exam. This is as well the final chapter of the PHP ZCE exam preparation.

Sessions

This is a part that describes what sessions are how they are created. You should know as well where they can be stored. There are a couple of php.ini settings to get familiar with as well f.e. session.use_only_cookies. Get to know the session functions and handlers as well. More about that on PHP manual.

Forms

Forms are the primary way of sending data to an application. Any developer that is thinking about taking the exam should have a good understanding of what forms are. Some things that are worth mentioning here are:

• Superglobal arrays : learn all about those and how data is passed by them.
• Encoding & decoding : Check the manual on how to encode and decode data passed from and to the server.
• File uploading : This is a special part of the forms subject. Make sure you know all about $_FILES array and remember the enctype parameter should be set to ‘multipart/form-data’.

Cookies & Headers

This part focuses on creating and getting cookies from user’s client and the headers that could be sent to the user. This is fairly simple and straight forward. Just to mention you should remember all the parameters that can be set when calling setcookie function.

When talking about headers it is not only important to know how to send them but checking if they are sent or getting a list of headers to be sent is important as well. Get familiarized with the header functions available in the manual. Make sure you know the HTTP header codes and what each of them means.

This is it ! Now you should be ready for passing the PHP ZCE exam. I hope that my series of preparation articles helped someone to reach the goal of passing the exam Thank you for reading

This is probably the hardest chapter of the exam and one that is strongly emphasized.

Configuration & Installation

Read all about installing PHP as CGI binary or as an Apache module, which is most likely the way you have done it usually. It is crucial to understand the way how the redirect mechanism works. The thing to focus on here is the possible measures to protect your folders from unwanted access. You can read more about it on PHP.net’s Security section.

Attacks

There are couple of attacks mentioned in the chapter and you should really focus on how PHP applications are attacked and where are their vulnerabilities. Here’s a list what you should look up thoroughly:

• Session attacks : Two methods here to read about are session hijacking and session fixation. You can read more about the first one on Server-Side Magazine’s “Session Hijacking” and the second one on Chris Shiflett’s “Session Fixation”.
• Cross-Site Scripting (XSS) : An attack that is based on injecting HTML, CSS or JavaScript into the page. More about XSS on Wikipedia.
• Cross-Site Request Forgery (CSRF) : Attack that relies on web site’s vulnerability of trusting logged in users. You can read more about CSRF’s and counter measures on Chris Shiftlett’s blog as well.
• SQL Injection : Probably one of the most popular attacks incorporating SQL syntax which may break not-escaped queries and expose the whole database. More about the subject on Krzysztof Kotowicz’s “Hardening PHP: SQL Injection – Complete walkthrough”.

There are of course a lot more attacks like for example : Remote Code Injection, Email Injection, but you should strongly focus on those mentioned above.

Input & Output

When considering security you should always have in mind the two fundamental rules:

1. Filter and validate input
2. Escape output

When displaying output on the page always remember to escape it. You can use specially designed functions for that like: strip_tags, htmlspecialchars, htmlentities.

File uploads

Although this is a fairly easy part, this is a subject that has some some strong focus on the exam. Try to learn everything about upload files, the superglobal $_FILES, and some helping functions like: is_uploaded_file, move_uploaded_file.

There are some other subjects in this chapter like encrypting passwords, designing databases and SSL but this should be very well know the ones mentioned above should be your primary focus considering the exam.

SQL

This chapter focuses on some of the topics related with databases. For example SQL is one of the key points of this part. This should not be an issue for people that want to pass the exam because the questions mainly consist of standard SQL queries like SELECT, INSERT, UPDATE, DELETE. One thing that is crucial here is that you have a good understanding of the difference between LEFT JOIN’s and INNER JOIN’s.

PDO (PHP Data Objects)

This chapter focuses strongly on PDO. There are some topics in relation with PDO that are worth looking into:

• Transactions: Get a good grip of commiting and rolling back transactions. You can read more about it in the Transactions and auto-commit article on PHP manual.
• Prepared statements: This is a strong feature of PDO as it emulates the behaviour even for the adapters that do not support prepared statements. Read more on Prepared statements and stored procedures at php.net.
• Connections: Lear about how to initiate a connection and how to close one.
• PDOStatement: Read more about the class here. The thing that you could focus on is the many ways of getting the results from the database. Try to learn about the fetch modes when executing a query.

As you can see the SQL part of this chapter is very simple and straight forward. I assume most of the people know a lot already about SQL so the only point to focus on here is the PDO extension which you should get familiarized with.

Object Oriented Programming

Most of the rules mentioned in this chapter apply to a great majority of programming languages, so assuming you have some experience with software this should be just a good reminder. Although this chapter has some general ideas of programming there are some PHP specific issues here and there. Take a good look at this one because it is filled with tricky questions. Some topics that are worth mentioning:

Reflections

Reflections are a good tool to investigate your classes or dynamically modify them. This is very often used to create documentation files from a set of PHP classes. The main advantage of reflections is that you can handle dynamic method calling in an elegant way. On top of that you can set static properties in classes and modify the accessibility of fields. This is a powerful tool for dynamic definition of code.

Autoloading

Try to learn everything about the autoloader mechanism. How does it work and how to modify it. There is a good example of autoloading on Wayne May’s blog.

Late Static Binding

This is a new feature in PHP 5.3 and it is a one that was needed for a long time indeed. Now when you call an inherited method of class you can call static methods from the initialy called class rather than parent class with the use of static:: - for examples see the PHP manaul.

Inheritance

Focus especially on questions concerning method overriding. This ones are ment to be tricky with all the variations of overriding. Think of all the abstract/static method modifiers possibilities. Keep in mind that code leading to fatal errors may come up in questions as well.

Magic Methods

Although they are not used often magic methods are key feature of some PHP frameworks. For example Symfony 1.x used them extensively in many aspects. So if you feel like designing a new big project/framework you can consider them as a tool for you. Keep in mind that the current trend is to “get rid of all the magic” as the code is not always clear. More on magic methods can be found on NetTuts+ post

SPL

Standard PHP Library is library of interfaces that provide software developers to finally write PHP code in an object oriented manner. It comes with all sort of Iterators and classes that help construct object with array-like behaviour. I recommend reading this very good introduction to SPL that is available on Zend’s DevZone.

This is probably one of the easiest and shortest topics on the exam. But use it as your advantage – this is a great way to earn some easy points to help you pass the exam. If you are a PHP developer that considers taking ZCE exam I suppose you already know the subject by heart. Nevertheless here are some topics that are mentioned in this chapter:

Returning values: returning references from functions are something worth mentioning that may appear in some questions.

Variable scope: some questions may concern defining variables in and outside of the functions and their visibility in them. Remember about globals.

Arguments: Focus on passing arguments by reference, getting variable-length arguments lists.

Closures: Also known as anonymous functions. Often used as callbacks. Questions about inheriting variables from parent scope might apear. Read more here.

As you can see this one should be a piece of pie for you so use it on your advantage.

Reading and Writting

One of the key parts of this chapters is for you to focus on all the file_* and f* functions, which are great tools for file handling. All of them can be found here. So start off with the easy ones (file_*), which work with a filename. Then go to the ones that work with a resource (f*).  Memorize all the possible ways to open a resource – you can find all the modes in the fopen documentation. While you’re at the resource based file functions try to get familiar with manipulating the file pointer in the resource with functions like fseek, ftell or rewind.

File Operations

At this point you can focus on functions that are helpfull with operating on files. For example you should be studying topics like : how to read the directory contents, how to copy files, how to delete them or how to determine if a file/directory exists. There’s a lot of helpful functions for this matter. They on the list with the previous ones. Most of them have very straight forward names : copy, delete, rename, file_exists. Some of them are named exactly the same as UNIX shell commands : chgrp, chmod, chown so this should be easy to remember.

Streams

This is probably the hardest part of this chapter so if you’re not familiar with streams in PHP you’ve got some catching up to do. First off you can never go wrong with going to the manual. There are very many useful functionalities concerning streams, for example: learn a thing or two about stream contexts. Thanks to them you can give some extra headers to the stream which is often the scenario you will need. Another useful thing about streams is stream filtering. You can define your own filters that will modify the data of the file while it’s being read in your script. You can read about registering your filters in the manual as always. If you’d like to read more about streams I would recommend sk89q’s introduction to PHP streams.

Basics

Arrays are probably the strongest and best tool in PHP for data manipulation. There are dozens of specially prepared functions just for handling arrays. I assume that you are already well familiarized with the basics of creating, adressing, splitting and looping through arrays. Though these are very simple points of the exam, try to focus on some variations of adding and removing elements like for example:

• array_push
• array_unshift
• array_pop
• array_shift

Sorting

There are very many ways of sorting an array in PHP. The key here is to know all types of the sort functions and what they do:

• sort
• rsort – reverse sort
• asort – associative sort
• arsort – associative reverse sort
• ksort – sort by key
• krsort – sort by key in reverse
• usort – user defined sort
• natsort – natural sort

Try to memorize all of them and the set of parameters that they take f.e. the sort mode :

• SORT_LOCALE_STRING – sort based on locale settings
• SORT_NUMERIC – numeric sort
• SORT_REGULAR – normal sorting
• SORT_STRING – sorting as strings

It is very crucial to know the difference in how those modes work and what would be the outcome of sorting in each of those modes.

Comparing

There is a big family of function in PHP that are defined for comparing arrays and getting their differences or elements that are present in each. For checking out the differences there are a lot of functions that start with array_diff or array_udiff for user defined calculations. The same goes for checking the elements present in one array that are available in the other – this time we have functions starting with array_intersect or array_uintersect.

SPL

Standard PHP Library introduced a new helpful aproach for creating arrays. Now by extending the ArrayObject class delivered with SPL we can define our own logic in accesing, iterating, serializing or sorting array elements. This can be very helpful in many ways for example: we could want to throw a custom exception when accessing an illegal offset in array. This is a very powerful tool and try to focus on getting to know it better.

String manipulation

Besides the real basics of strings in PHP (like f.e. escaping, heredoc syntax, determining the length) you should focus on some of the essential tools that PHP provides for string manipulation.

First of all try to focus on comparing, searching and replacing strings. Try to memorize as many function from PHP manual as you can. A good way to start would be to group them in functionalities f.e.:

Searching:

• strpos
• stripos
• strstr
• stristr

Replacing:

• str_replace
• str_ireplace
• substr_replace

Formating:

• printf
• vprintf
• sprintf
• vsprintf
• fprintf

Encoding

After you get a grip with all the string manipulation techniques a good thing to do would be to get familiar with encodings. This is a thing that from my experience is often the cause of some serious and hard to fix application bugs. So try to learn everything about the changing and determining the encoding of characters in strings.

Regular Expressions

Last but not least probably the hardest part in this chapter are regular expressions. This is a tool that will make you a very powerful and skilled developer if you know it very good. But don’t be fooled, it’s very easy to mess everything up with some wrong or greedy regular expressions. RE are in my opinion not something that you can learn overnight. It takes some practice and a couple of mistakes to get a good grip of them. So try to practice as many regular expressions as you can find. The Regular Expression Examples is a good site if you need some inspiration or a point of start.

This is the first part of the exam on which we can actually focus some more. There are some points here that tend to be troublesome or tricky like f.e. xpath queries. From my experience this chapter describes some crucial tools for a PHP developer that make life easier. Besides data formats, the concept of a web service is a key point of this section as well. So let’s get the show on the road:

XML : Besides the basics, like understanding DOM or creating XML parsers, the main focus in here would be to get a good grip of SimpleXML. Read about the classes and methods that PHP offers in an OOP access for XML data. As a part of SimpleXML study, focus on the xpath section. This is a crucial thing as the questions may be tricky for this one.

SOAP & REST : This shouldn’t be a hard to learn one, because those are pretty straight forward. Try to learn as much as you can about REST principles and focus on SoapClient communication with SoapServer and the functionalities that they both have to offer.

Date & Time : Every PHP developer should have a good sense of how to manipulate with date and time formats. Nevertheless try to refresh your memory about the formats in which the time is displayed, some php.ini date.* settings and get familiar with the DateTime class which is not commonly used.

This chapter covers some others stuff like f.e. JSON & AJAX but I think every developer (not only PHP) should know them pretty well, so as it’s not a matter of learning them, you can have a look and double check if you still know everything about them.

Till next time

Most of the people who will want to take this exam will probably know a thing or two about PHP. Major part of this exam section is something that goes without saying. As a developer you should be familiar with the language syntax and already have written a fair amount of PHP code.

Although this one should be a piece of cake, there are some key points of this chapter that are worth studying deeper. For example:

• Namespaces : a great new feature that was introduced with PHP 5.3. They are not yet as popular as one would expect so many developers didn’t have a good grip of them yet. People working with modern frameworks like Symfony 2 or Zend 2 should have a good sense of what namespaces are, but If you don’t I recommend to have a good look at them. The parts that are especially worth focusing on are importing and aliasing of namespaces.
• Configuration: it is always good to refresh your knowledge or learn something new about php.ini files. The main focus here would be to read about the settings that are available and if you already know most of them then try to memorise them so as not to mess the settings names. See PHP manual for more.

As you can see not many fields to focus in this chapter but don’t neglect it. Make sure you are prepared for questions that seem innocent at first glance but for example have some tricky bitwise operators.

I’m currently in the process of preparing for my ZCE exam for PHP. Some time ago I had an idea to turn this whole learning process into a set of articles/blog posts. This could help me to sum up some keynotes about some of the main points of the exam. Hopefully this would help someone there preparing for the exam as well.

At first I thought of some kind of day-by-day walkthrough but I don’t think I would have the time to become a pro-blogger by posting an article each day. Then I came up with the plan of organising these articles into chapters, so each chapter would address a certain part of the exam.

My intention is not to deliver a tutorial on how to prepare for the exam, but to document the learning process. Maybe point out some hints or things that I think are worth focusing on.  This could help some people to get a grip of the ZCE exam. Last but not least this could help me as well. I count on your comments.

Mocknity is an extension for Microsoft’s Dependency Injection Container – Unity, which turns the Patterns & Practices Container into an Auto Mocking Container. Mocknity uses Rhino Mocks for creation of mock objects.

The Idea

The basic idea of auto mocking is to minimize the huge amount of boilerplate configuration that you need to repeat for your Dependency Injection in different environments. In most cases they differ only by 2-3 dependencies and the rest is just copy & paste.

Thanks to an Auto Mocking Container you need to specify only the dependencies that you want to be resolved with class instances that will be tested in the unit tests.

The way it works is similar to the Dependency Injection Container (which it is based on) but instead of resolving certain registered interface-to-class mappings it resolves them with mock objects. An object’s dependencies that are declared as interfaces and were not registered earlier will be mocked. This way you can focus on the unit testing and forget about filling in the dependecies.

Examples

[TestClass]
public class MocknityTests
{
  IUnityContainer container;
  MocknityContainerExtension mocknity;
  MockRepository repository;

  [TestInitialize]
  public void TestInitialize()
  {
    container = new UnityContainer();
    repository = new MockRepository();
    mocknity = new MocknityContainerExtension(repository);
    container.AddExtension(mocknity);
  }

  [TestMethod]
  public void ResolveObject__MockDependenciesNotNull()
  {
    Car car = container.Resolve<Car>();
    // ... aserts go here ....
  }

}

This example shows how to configure Mocknity for your test class. You have to instantiate it with a mocking repository provided by Rhino Mocks. Upon resolving an object by the container, all it’s dependencies will be mocked if needed.

Let’s say that Car instance has two dependencies : IWheels and IEngine. Those two will be mocked in the scenario above.

Strategies

Mocknity comes with three types of strategies for building mocked dependencies:

• DynamicRhinoMocksBuilderStrategy (default)
• StrictRhinoMocksBuilderStrategy
• StubRhinoMocksBuilderStrategy

The first one is the most flexible scenario thus making it the default strategy. StrictRhinoMocksBuilderStrategy on the other hand gives you mocks that you have to make certain expectations for them to work properly. The last strategy is only for stub creation.

This following example shows how to set a strategy for certain interface and shows the behaviour of a strict mock which will throw an exception when asked for something that wasn’t declared expected:

[TestMethod]
[ExpectedException(typeof(ExpectationViolationException))]
public void IWheelsIsAStrictMock__ExceptionThrownOnCallingNotExpectedMethod()
{

  mocknity.setStrategy<StrictRhinoMocksBuilderStrategy>(typeof(IWheels));
  Car car = container.Resolve<Car>();
  mocknity.getRepository().ReplayAll();
  car.wheels.Spin(); // this will throw an exception
  mocknity.getRepository().VerifyAll();

}

You can download the code and the DLL binaries as well from github. Hope this helps