I started this journey to begin with, Codeception php testing framework. First of all I would conclude before I go on to share my experience that this is one of the best testing framework around now – you can talk about the simplicity and versatility it ensures, and easy integration with other PHP frameworks (Laravel e.t.c) and using different web drivers (Selenium etc) almost seamlessly.

My own tale of this adventure started when I had to use it on PHP 5.3.3. Yes, it was succesfully installed using:

Of course strangely it got installed and it was time to try out some example at first from Codeception Web Services testing docs. If the whole system was configured properly and the installation goes as expected then simply writing:

codeception

Expectantly, there was no error response, after a further trial to no good signal to tell whether it works or not, I got to know that the installed version of Codeception was higher version and so the 1.8.7 version was later installed, and now this seems to look good, however this is where the adventure starts.

Most of the documentation on Codeception’s page consists of those commands and configurations that would mostly function on their 2.X versions, this made a serious challenges on my side as I delve to search for writing my first Web Service test with this framework.

Earlier I had installed and even written the API tests on my local computer, and everything works smoothly because I was using the latest version of the testing frameworks, therefore as described on the website there was no cause for concern. But when I had to do it on the development environment I was later working on, here the problem ensure.

It is notable that I had figured out one of the major concern that I had to look out for. Number one is the fact that it is of different version and by the way what are the differences I found out?

There was more of *Guy* kind of bootstrap result when an attempt is made to bootstrap a boiler plate for the implementation of other tests. This is done with a simple:

codecept bootstrap

So simple as it is yet powerful, by this command necessary configuration and some codes and files needed to get started are auto-generated into a directory called tests: these includes some folders and yml files for functional, unit, and acceptance tests. The basic example of the above result is like this (one on the latest version of codeption and the one on the version 1.8.7):

Version 2.2.4

Version 1.8.7

As you can see that there is a difference between the two, one has _data, _support, and _output directory. The support directory under the newer version is where the tests helpers files are placed while in the version 1.8.7 there is a helpers folder directly under the main test directory. So having attempted the test with the newer version without an itch, it became a bit of a challenge to understand the structuring under the old version.
This my experience may be more useful for those working on the older version of Codeception.

The version 2.X uses the type of test actions in the generated folder under _support folder, also the helpers as earlier said are under the _support > Helpers directory given the name of the test or suite(s) themselves. In contrast, the test actions stays in 1.8.7 under the suite directory itself and commonly have the word Guy with it.
It is in these kind of files you will find this text:

// This class was automatically generated by build task
// You should not change it manually as it will be overwritten on next build
// @codingStandardsIgnoreFile

Finally, since I was trying to test API I had to generate a suite for it with:

 codecept generate:suite api

According to codeception’s documentation this should create new test suite which requires suite name and actor name. An example is given: codecept g:suite api which should give api+ApiTester. But in 1.8 it doesn’t work that way, you have to specify the two arguments therefore no matter how hard I tried to rerun the codecept generate suite command without the second argument it tells me Missing argument.
The above works normally on the latest version but not on the version I am on. So at the end of the day, in order to start the process of testing the API I had to run the following:

codecept generate:suite api ApiGuy

I used ApiGuy just to following the Guy kind of convention though.

Now that the ApiGuy is created for me, then the big difference here that is worth the mention now came up and that is the configuration of api.suite.yml. The basic configuration of the Helpers, dependencies, and maybe the url for the test suite is done here and for the newer version of codeception, it requires each dependencies on different itemized line while for the older version it has to be in a group together as though an array. I attempted to follow the documentation by using this format:

class_name: ApiGuy
    modules:
         enabled:
              - REST:
                  url: http://localhost/api/v1/
                  depends: PhpBrowser
                  part: Js

On running codecept build then errors came up that I needed an array. I tried several means of understanding the problem until I checkout out the Question posted on PHP Test Club about an issue with Php fatal error REST::_inject() then I started understanding the wide margin for the old and new configuration and the good news is that this is the way it should actually look like:

class_name: ApiGuy
modules:
    enabled: [ApiHelper, REST, PhpBrowser]
    depends:
          REST: PhpBrowser
    config:
         PhpBrowser: 
            url: http://localhost/apis/
         REST:  
            url: http://localhost/apis/v1
    part:
        REST:
            Json

So with this, after codecept build everything went so well and the ApiGuy.php was bootstrapped successfully under the api directory for new test.

4. The next thing was to create my first Cept (scenario-driven) test for this purpose, even though there is Cest (scenario-driven object-oriented) test. But in my case I wanted to begin with Cept test so generating a starter php file for the test unlike others had no difference when using:

$ php codecept generate:cept api ListUsers

My ListUsersCept.php file was generated as expected in the api sub-directory, but I noticed a difference after I had copied the test I wrote on the newer version to this version with this code:

$I = new ApiTester($scenario);
$I->wantTo('list users via API');
$I->amHttpAuthenticated('service_user', '123456');
$I->haveHttpHeader('Content-Type', 'application/x-www-form-urlencoded');
$I->sendGET('/users',['username'=>'omitobisam']);
$I->seeResponseCodeIs(\Codeception\Util\HttpCode::OK); // 200
$I->seeResponseIsJson();
$I->seeResponseContains('{"result":"ok"}');

This $I->seeResponseCodeIs(\Codeception\Util\HttpCode::OK); gave an error that it couldn’t trace the HttpCode so this broke down, therefore my final code after I had stumbled upon this post written since June 19, 2016 is:

$I = new ApiGuy($scenario);
$I->wantTo('list  users via API');
$I->amHttpAuthenticated('service_user', '123456');
$I->haveHttpHeader('Content-Type', 'application/x-www-form-urlencoded');
$I->sendGET('/users', array('username'=>'omitobisam'));
$I->seeResponseCodeIs(200); // 200
$I->seeResponseIsJson();
$I->seeResponseContains('{"result":"ok"}'

Now, that I have analysed some differences I found out, I have to really say my major negligence for going through the stress for like 2 days to solve my problem was that the version of PHP I was on is 5.3.3 and on Codecepion builds page It was stated that from 2.0 and above requires PHP 5.4 and above to run. So my main point of search should have been from the point of the version of codeception and the limitations that exists with using the version that suites the environment I am working on.

Isn’t it challenging and yet inspiring? I believe, on my own side it is. So if you stumble upon codeception with old php version, you might want to update your PHP version or just come down to enjoy the things the older version of Codeception can offer.

This is #tobisoft #omisakinoluwatobisamuel