Archive for October 2010


Speaking at CodeWorks 2010 : Austin

October 29th, 2010 — 9:10am

Since Marco Tabini won’t be able to make it to the CodeWorks Austin spot this year, Keith Casey asked me if I could fill his spot and give his talk on working with the object oriented features that the PHP 5.3.x series has to offer. Here’s his summary:

With version 5.3, PHP has finally acquired a well-rounded object-orientation model that rivals – and in many way exceed – those of most other languages, while maintaining PHP’s trademark simplicity and ease of use. In this session, Marco will explore the new OOP features in 5.3 and show you how they can improve your coding.

There’s other great talks coming along with the tour that’ll fill you in on things like unit testing strategies, building effective APIs and scalability. If you haven’t picked up your ticket for the Austin stop and want to join us on November 13th (a Saturday), you can still grab a ticket. Full admission for the day packed full of great sessions and community interaction is $100 USD and, if you’d like to purchase a ticket for the Day Camp 4 Developers event, it’s only another $10 USD on top of that!

Come on down (over/up/above?) and join us for this great day-long event!

Comment » | PHP, Presentation

API Testing with Frisk (and Joind.in!)

October 25th, 2010 — 9:51am

Two great tastes taste great together, right? As I’ve been working more on Frisk in my spare time (yes, there’s a little in there between PHPDeveloper.org and Joind.in) I’ve been trying to develop features for it that would be helpful not only for testing web site interaction, but also in working with other kinds of web-based interfaces. Naturally, my thoughts wandered over to the Joind.in API and how I could use Frisk to work with and test the responses it gives.

I’ve added a few more handy things lately – like matching values inside of JSON objects and different output options – but one of the latest things is an improvement to the POST and GET handlers to allow for more verbose options on requests. This comes in handy when we want to test something a bit more technical than just your average web site.

First, if you just want to check out the test, here’s the code in a handy .phps file. It’s the sample test I’ll be describing.

public function testSiteStatus()
    {
        // This is our object to send
        $postData = json_encode(array(
            'request'=>array('action'=>array(
'type'=>'status','data'=>array(
'test_string'=>'my test'))
        )));

        // This is what the object that comes back should look like
        $response = json_encode(array(
            'dt'=>date('r'),'test_string'=>'my test'
        ));
        
        // Build the settings for the connection
        $settings=array(
            'location'         => '/api/site',
            'host'            => 'ji-enygma.localhost',
            'postData'        => $postData,
            'outputFormat'    => 'json',
            'headers'        => array(
                'Content-Type'=>'text/json'
            )
        );

        // Make the request and check the response!
        $this->post($settings)
            ->assertEquals($response);
    }

The large part of the example test is made up of the “setup” to even make the test happen. In $postData I’ve created a JSON message based on what the Joind.in API is expecting for the Site/Status request and pushed it into a string. The second JSON object, $response, mimics what the API’s response will look like. The $settings array is the more verbose way of specifying settings for the ActionPost request (including the additional headers). The Joind.in API requires that you give it a Content-Type of the message you’re giving it – it’s not a very good guesser.

The next two lines do all of the work – make the post request to the remote API, return the message and check to see if it’s the same as $response. Simple, right?

If you wanted to get a little more fancy with checking, you can use the “paths” in the assertContains to look inside of a JSON object. So, you could do something like:

<?php

$this->post($settings)
     ->assertContains('look for me','message_list/message/message1');

?>

That will look at “message1″ in this JSON to see if it contains that “look for me” string:

{“message_list”:{“message”:{“message1″:”I think you should look for me”,”message2″:”but not here”}}}

You can find out more about the Joind.in API and all it has to offer on the Joind.in site and for more information on Frisk, check out it’s project on github.

  • Joind.in API – Interface directly with Community events & feedback
  • Frisk – automated functional unit testing

Comment » | joind.in, PHP, Testing

Test with Frisk!

October 17th, 2010 — 2:49pm

For a while now, I’ve had a renewed interesting testing applications – unit, functional, performance, etc – and have been learning all I can about the software you can use to run these tests. Obviously, one of the mainstays of the PHP world is PHPUnit for unit testing. There’s a few others out there that are good for other kinds of testing – too many to name (and lots that aren’t written in PHP).

Lately, though, I’ve been looking more at testing the frontend of applications and their flow. I started looking around at the current testing tools and found some I wanted to use, but I wanted more to know how they worked. So, as an exercise, I started on Frisk, a light-weight simple testing framework that has some of the basics of functionally testing, nothing fancy though. Oh, and of course it’s open sourced so you can take a look at the work behind it too.

It’s not a complete testing tool, but it does work. I’ve thrown together a simple example of how I’ve used it to test two things on the Joind.in site – the homepage content and the result of a login:

JoindinTest.phps

When this file is dropped in the “tests” directory and the “frisk” executable is run, it’ll execute these tests and check the results of those requests. The “ji-enygma.localhost” is a reference to my local Joind.in instance. The results are spit back out as a PHP array that reports the results of each part of the test (pass/fail) split out by test function name and action/assert result:

Start!

=====================
ending status: Array
(
    [JoindinTest] => Array (
            [testHomepageContent] => Array (
                    [ActionGet] => Array (
                            [0] => pass
                            [1] => 
                        )
                    [AssertContains] => Array (
                            [0] => pass
                            [1] => 
                        )
                )
            [testValidLogin] => Array (
                    [ActionGet] => Array (
                            [0] => pass
                            [1] => 
                        )
                    [ActionSubmitform] => Array (
                            [0] => pass
                            [1] => 
                        )
                    [AssertContains] => Array (
                            [0] => fail
                            [1] => AssertContains: Term not found
                        )
                )
        )
)

The project is hosted on Github so you can grab the source, fork it and play with the assertions and actions (or helpers!) and check out the project wiki for complete details on what the project has to offer.

2 comments » | PHP, Testing

Back to top