This feature makes it difficult to integrate testing of such APIs with the main test-suite. Since we use Travis-CI for online testing, we would have to create an extra connection setup for online testing and offline (localhost) testing.

So in this dilemma, I had to come up with an approach which would allow the test-suite to recognise Travis-CI and take necessary actions to handle such conditions. After some reading, I came across PHP’s getenv() function which provides information of current environment variables.

So, in order to write tests for localhost-only APIs, I used getenv() as a check to differentiate between Travis and local tests.

Using this approach, tests for Settings and Accounts API were added. Code samples shown below!

This approach improves the tested code-coverage and integrates all unit tests into one file!

I spent most of this summer working on wordpress plugins. So when we were up with a substantial amount, we wanted to test them online. I discussed in a previous blog-post regarding putting an online wordpress implementation through Heroku. Once I was done with internal testing, the plugins were supposed to be released for common testing. Now, since we did not want to risk our service, we couldn’t provide admin rights to new users. So in order to overcome this problem I had the following options at my disposal:

Create a script which would automatically activate and configure all plugins and show a basic plugin interface to users who are not logged in; OR

Create a user with lesser privileges than administrator, but enough to view and modify plugin settings.

The problem with the first approach was its static nature. A user would not be able to test your service if he is not leveraged with all options your program provides. So, in order to ensure rigorous testing, I used the second approach.

WordPress, by default, provides 5 user-types:

Administrator

Editor

Author

Contributor

Subscriber

As none of these user profiles fit the required job specification, I had to create my own user-type. After some brainstorming and searching, I found a pretty useful WordPress plugin (User Role Editor) which creates custom user profiles based on actions already present in WP suite. Once I installed the plugin on our WP installation, I used following steps to create my own user-profile called Loklak Tester.

Click on ‘Users’ menu and then click on ‘User Role Editor’.

Here I selected the privileges I wanted for my user. Some of them are shown in the figure.

Once I was done, I clicked on Add Role and provided the required user-type name.

Creation of this new user-profile would allow users to login using its credentials. Activate/deactivate, modify, edit plugins and change their settings. This would later act as a demo testing user which could be used by our audience to test our plugins on variety of levels.

This week, I added tests for suggest, map, markdown, push and susi APIs and fixed tests for user topology related queries. PHPUnit was used as the testing framework since it provides code-coverage support.

Loklak PHP API now has a good test-suite support and associated examples to help you use our services

In above process, code-coverage was increased from 33% to 61%. Test-suite continuously updated as new APIs are added to Loklak.

Source support for Search API

Apart from that, since Loklak is scaling beyond Twitter. Source argument has been added to the search API to define the source of search results. As far as wordpress plugins are concerned, since they only require twitter results for now, source has been added as a default argument. See below code: