GPUG.ca - Guelph PHP Users Group

GPUG 2.6: Building Test-centric Teams

jeremy — Thu, 21 Mar 2013 01:08:53 +0000

Our guest speaker this month will be Chris Hartjes, better known to many as The Grumpy Programmer. He’ll be speaking on building test-centric teams.

GPUG 2.4: Introduction to Twig

jeremy — Thu, 21 Feb 2013 01:56:11 +0000

Our speaker this month will be Mark Story, senior developer at Freshbooks and project lead of CakePHP. He’ll be talking about the popular templating language Twig, which he is a contributor to.More information can be found on the GuelphPHP page on Meetup.

GPUG 2.2: Open Mic Night

jeremy — Wed, 05 Sep 2012 00:57:20 +0000

This month we’re switching it up and handing control over to our group members. This is your chance to drop some essential wisdom on your fellow GPUGites, talk about anything relating to PHP and web development. What new and exciting tools are you using to make your life easier? Tired of being made fun of for using EMACS by ignorant VIM users? Show us the light then!

We’re capping the length of each talk to 20 minutes, if you only need 5 minutes then great, we can have 3 other talks just like it. Need more than 20 minutes? Let’s talk about doing a full length presentation in 2013 (considering the world doesn’t end on 2012/12/21).

Open Mic Night is going to be an intense, concentrated throw down of web dev know-how! Strap on your boots and hold on tight!

GPUG 2.1: All about Selenium

jeremy — Wed, 05 Sep 2012 00:56:05 +0000

This month a guest speaker from Freshbooks will be presenting the Selenium testing framework to us. Come and find out how to automate your browser testing as part of your test suite and build process while meeting other PHP developers and enjoying a few snacks.

GPUG 2.0: The Anniversary Edition

jeremy — Wed, 05 Sep 2012 00:54:30 +0000

It’s hard to believe but September is our first anniversary as a group! Ilia Alshanetsky, who gave our first talk in September 2011, will be back to present the new features that are available in PHP 5.4 to us and they’ll be the usual mix of socialising and snacks. We’ll also have a few freebies for members too.

Testing Protected Methods with PHPUnit

colin — Sat, 02 Jun 2012 20:10:33 +0000

Alright, I know that idea of ‘testing protected methods’ makes some people cringe. That instead of directly testing your protected methods you should test them indirectly via the public methods. I can support that argument, after all, as long as the code is being tested we’re doing our jobs. BUT when tests start to fail where’s the break? is it the public method? or the protected method? maybe you’ve royally fucked something during a refactor and you broke them both … who knows? This is why I personally think that directly testing your protected methods is a good thing, and, since I’m the one writing this post, it’s the right thing to do as well.

Let’s start with an example, let’s say you’re working on this amazing new framework and it’s going to change the world and win you thousands of twitter followers. However, before that happens you need to make sure that you’ve got decent coverage and everything appears to work. Part of your framework deals with persisting uploaded files and since this is the most amazing and flexible framework evar, you’re planning on giving multiple options for persistent storage. Users of the framework can choose to persist their files to the local filesystem (boooring), they can store them in some sort of webscale document store (like /dev/null maybe) or they can even choose to put them up in the cloud because clouds are fluffy and great and that’s where the Care Bears live.

I’m an OO programmer and to me, this use case absolutely begs me to use an abstract base class for the plain jane logic and then a set of subclasses to deal with specifics. Let’s move ahead then and start writing some code. Our base class is going to have a public method called persist, if everything goes as planned, the persist method will move the uploaded file from it’s temporary place on the filesystem to it’s more permanent home on the filesystem/in the document store/in the cloud/where ever. Also, because we’re good developers, the method is also responsible for logging the success or failure of this method.

Side Note: this is probably a good time to mention that all the examples here are available from our GitHub blog-post-examples repository

Here is the persist method from the abstract base class Persister

_persist(); } catch (\Exception $e) { // this exception will have some nitty gritty details useful for logging $this->_logger->log( 'Unable to persist uploaded file: ' . $e->getMessage(), Logger::LEVEL_OHNOES ); // throw a new friendly exception throw new \Exception( 'We were unable to store your file, maybe retry a little later?', 0, // we don't need no stinking error codes $e ); } $this->_logger->log('Successfully stored uploaded file in: ' . $this->getLocation()); return true; } // moar interesting bits down here

and here are the nitty gritty details of the _persist method in the Persister subclass File

_location = tempnam(sys_get_temp_dir(), 'UL-'); if (!$this->_moveUploadedFile()) { unlink($this->_location); $this->_location = null; throw new \Exception('error moving uploaded file'); } } // interesting bits

Great, we’ve got some code, time to test it. I’m going to focus on showing how to test the protected _persist method of the File subclass but remember since we’re directly testing the protected method we’ve also got to test it’s caller separately. Those tests have been written as well and be seen here if you don’t believe me. Onto the testing …

Method 1: Reflection

PHP’s Reflection API is really handy for doing things your mother told you not to. If you haven’t mucked around with it I really recommend doing so, you can reach into objects and fiddle with their private bits and, as in this example, make protected methods a little more accessible.

logger); $reflectedPersist = new \ReflectionMethod($filePersister, '_persist'); $reflectedPersist->setAccessible(true); $reflectedPersist->invoke($filePersister); $persistedLocation = \PHPUnit_Framework_Assert::readAttribute($filePersister, '_location'); $this->assertRegExp('/UL-/', $persistedLocation); $this->assertTrue(file_exists($persistedLocation)); $this->assertEquals("Hello World\n", file_get_contents($persistedLocation)); } public function test_protected_persist_directly_with_refelection_failure() { $filePersisterMock = $this->getMockBuilder('GPUG\Examples\Persister\File') ->setConstructorArgs(array($_FILES, $this->logger)) ->setMethods(array('_moveUploadedFile')) ->getMock(); $filePersisterMock->expects($this->once()) ->method('_moveUploadedFile') ->will($this->returnValue(false)); $reflectedPersist = new \ReflectionMethod($filePersisterMock, '_persist'); $reflectedPersist->setAccessible(true); try { $reflectedPersist->invoke($filePersisterMock); } catch (\Exception $e) { $this->assertNull(\PHPUnit_Framework_Assert::readAttribute($filePersisterMock, '_location')); $this->assertEquals('error moving uploaded file', $e->getMessage()); return; } $this->fail('Expected exception was not thrown in test_protected_persist_directly_with_reflection_failure'); } // interesting bits

Method 2: A ‘Testable’ Subclass

If reflection isn’t your thing you can always define a subclass of the Class Under Test (CUT) which has public wrapper methods of the protected methods you want to test. These classes are typically defined at the bottom of the CUT’s test case file, here is the definition of the TestableFile subclass.

With the TestableFile subclass defined, testing the protected _persist method is really simple.

logger); $filePersister->_persistWrapper(); $persistedLocation = \PHPUnit_Framework_Assert::readAttribute($filePersister, '_location'); $this->assertRegExp('/UL-/', $persistedLocation); $this->assertTrue(file_exists($persistedLocation)); $this->assertEquals("Hello World\n", file_get_contents($persistedLocation)); } public function test_protected_persist_with_testable_subclass_failure() { $filePersisterMock = $this->getMockBuilder('GPUG\Test\Examples\Persister\TestableFile') ->setConstructorArgs(array($_FILES, $this->logger)) ->setMethods(array('_moveUploadedFile')) ->getMock(); $filePersisterMock->expects($this->once()) ->method('_moveUploadedFile') ->will($this->returnValue(false)); try { $filePersisterMock->_persistWrapper(); } catch (\Exception $e) { $this->assertNull(\PHPUnit_Framework_Assert::readAttribute($filePersisterMock, '_location')); $this->assertEquals('error moving uploaded file', $e->getMessage()); return; } $this->fail('Expected exception was not thrown in test_protected_persist_directly_with_reflection_failure'); } // interesing bits

Method 3: Indirection

Earlier I mentioned I could support the argument that you should test your protected methods indirectly by testing it’s callers from the public api … so here goes.

If you plan on testing your protected methods indirectly via the public api you need to stay focused on the purpose *and expected outcome* of each test. This method doesn’t mean you get to skip testing the public api separately. You should have a set of tests that cover the public caller of the protected method (in our case it’s the persist method of the abstract base class Persister). You can accomplish this by using Mock objects and stubbing the protected method call. This way your tests focus directly on the public method and it’s effects, not the effects of the protected method it calls out to. Similarly, when testing the protected method you only need to focus on the effects of the protected method itself.

logger); $this->assertTrue($filePersister->persist()); $persistedLocation = \PHPUnit_Framework_Assert::readAttribute($filePersister, '_location'); $this->assertRegExp('/UL-/', $persistedLocation); $this->assertTrue(file_exists($persistedLocation)); $this->assertEquals("Hello World\n", file_get_contents($persistedLocation)); } public function test_protected_persist_indirectly_via_public_persist_failure() { $filePersisterMock = $this->getMockBuilder('GPUG\Examples\Persister\File') ->setConstructorArgs(array($_FILES, $this->logger)) ->setMethods(array('_moveUploadedFile')) ->getMock(); $filePersisterMock->expects($this->once()) ->method('_moveUploadedFile') ->will($this->returnValue(false)); try { $filePersisterMock->persist(); } catch (\Exception $e) { $this->assertNull(\PHPUnit_Framework_Assert::readAttribute($filePersisterMock, '_location')); $this->assertEquals('We were unable to store your file, maybe retry a little later?', $e->getMessage()); $pe = $e->getPrevious(); $this->assertNotNull($pe); $this->assertEquals('error moving uploaded file', $pe->getMessage()); return; } $this->fail('Expected exception was not thrown in test_protected_persist_indirectly_via_public_persist_failure'); } // interesting bits

That’s it! Testing protected methods has never been easier. Remember, in the end it doesn’t really matter which method you choose. Whether it’s Reflection, a Testable Subclass, or Indirection, your code is being throughly tested and your app is better off because of it. You should feel good!

GPUG V 1.10

jeremy — Sun, 11 Mar 2012 15:47:48 +0000

This month Joël Perras will be our guest speaker. He’ll be presenting to us on NoSQL databases and Map Reduce.

GPUG V 1.9

jeremy — Sun, 11 Mar 2012 15:43:33 +0000

This month Kevin Bond will be giving us an introduction to Symfony 2. Come and find out how to leverage the power of this full stack PHP framework when building your own applications.

GPUG V 1.8

jeremy — Sun, 11 Mar 2012 15:32:11 +0000

Our speaker this month will be Colin DeCarlo of Freshbooks. He’ll be talking about using Liquibase to manage database migrations as well as how the tool can be integrated with continuous integration to set us easy, painless and reversible database changes.

GPUG V 1.7

jeremy — Sun, 11 Mar 2012 15:27:43 +0000

Our speaker this month will be Sean Yo. He’ll be presenting on why, how and when you might want to use Apache server side includes. We’ll also have our usual mix of socialising and food.