testing (7)

Codeception Testing – Part 2

I’m still setting up for BDD testing. All the basics are already there (see previous post).

I spoke quickly about setting up WPBrowser: WordPress specific set of extensions for Codeception. Here’s what to do (from the Readme):

  1. Require the package in the composer.json, then run “composer update” (details)
  2. Add the WPBrowser or WPWebDriver module in tests/acceptance.suite.yml (details)

The added bonus, if you’re using PhpStorm is that you will also get the related auto-complete package. And there’s plenty of functions that really speed things up.

Next for me was setting up MailCatcher

MailCatcher runs a super simple SMTP server which catches any message sent to it to display in a web interface

You need mailcatcher if you’re testing sending email out from the site. Here’s what I used:
\curl -sSL https://get.rvm.io | bash
source /etc/profile.d/rvm.sh
rvm install 2.2.2
rvm default@mailcatcher --create do gem install mailcatcher
rvm wrapper default@mailcatcher --no-prefix mailcatcher catchmail

You also need to add the following in /etc/php5/apache2/php.ini:

sendmail_path =  /usr/local/rvm/wrappers/default/catchmail -f some@from.address #

(and restart apache after that)

Next you need to install the codeception mailcatcher module using composer

"captbaritone/mailcatcher-codeception-module": "1.*"

And set the configuration inacceptance.suite.yml

You might get by with only that, but I had trouble with mail being routed through special plugins we use at work, so I had to install the ‘mailcatcher’ plugin

After that it was smooth testing …


Similar Posts:

Codeception Testing – Part 1

I started working on automating testing ( BDD style ) a few weeks ago, and it took me a while to go over the available tools and options. The obvious starting point was cucumber. Which then led me to Behat, which then took me to Codeception.

When someone tells you it works out of the box, you should always take that with a pinch of salt. Of course, if you follow the quickstart page, it will take you through the different steps that you would take to unwrap the shrink around the box, open it up, take the protective foam bar out, … You get my drift.

Turns out you would need a few more ingredients before you could start testing. Here’s what I needed:

  1. Download and run selenium
  2. Download and install chromedriver
  3. Setup PhpStorm with Codeception

Of course if you’re using the PhpBrowser for testing (no Javascript with that sorry),  you could get started faster. So no nagging please.

And, if you’re like me, going to test WordPress sites themes and plugins, you might find the WPBrowser very useful.

Here’s a list of the steps I took locally on an Ubuntu 15.10 machine (that already had Google Chrome installed)

If you didn’t have Chrome (or installing on a server):

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
dpkg -i google-chrome-stable_current_amd64.deb
apt-get install -f # dirty shortcut to get apt to install dependencies for you!

wget http://goo.gl/rQhaxb -O /opt/selenium-server-standalone.jar
sudo apt-get install xvfb
alias run_selenium="DISPLAY=:1 xvfb-run java -jar /opt/selenium-server-standalone.jar"

wget -N http://chromedriver.storage.googleapis.com/2.20/chromedriver_linux64.zip
unzip chromedriver_linux64.zip
chmod +x chromedriver

sudo mv -f chromedriver /usr/local/share/chromedriver
sudo ln -s /usr/local/share/chromedriver /usr/local/bin/chromedriver
sudo ln -s /usr/local/share/chromedriver /usr/bin/chromedriver

A couple of parting notes:

  1. WebDriver and PhpBrowser do not work together, one of them must be commented out when you’re testing. Pretty obvious when you think about it!
  2. When  you change browser to ‘chrome’, you should also add ‘http_proxy: direct’ in the acceptance.suite.yml

Similar Posts:

Drush in Jail Shell

I am not a drupal expert.
We got a request from a customer today asking to install drush in a jailed shell so that the user would only be able to run drush, but use it to do everything. Or at least this is how I understood the task.

Installing drush on CentOS (as root):

yum install php-pear
pear channel-discover pear.drush.org
pear install drush/drush

Do I need jailkit?
Here’s how to install jailkit:

yum install gcc make
wget -c http://olivier.sessink.nl/jailkit/jailkit-2.15.tar.bz2
tar xf jailkit-*.tar.bz2
cd jailkit-*
make install

The jailkit configuration files are in /etc/jailkit/

Jailing drush is in fact about jailing php-cli (or just php depending on your distro).

Turns out no scripts are needed (other than jailkit). I added the following to /etc/jailkit/jk_init.ini

comment = PHP and libs
paths = php
users = root, www-data, phpjtest
groups = root, www-data

comment = Drupal Shell
paths = /usr/bin/drush, /usr/share/drush, /etc/drush
includesections = php

And ran:

mkdir /srv/jail
chown root:root /srv/jail
chmod 0755 /srv/jail
jk_init -j /srv/jail jk_lsh
jk_init -j /srv/jail drush
adduser phpjtest
jk_jailuser -v -m -j /srv/jail phpjtest

Now to setup the drush alias:

mkdir ~/.drush/ # if not already there
vi ~/.drush/aliases.drushrc.php

with the following contents:

  'root' => '/var/www/example.com',
  'remote-host' => 'remote.host.ip.or.name',
  'remote-user' => 'phpjtest',

Next, set up a passwordless login to the remote server using:

# this is done on the client side (home pc)
ssh-keygen -t rsa
ssh-copy-id phpjtest@remote.host.ip.or.name 

And you should be able to run drush commands from the local machine using:
drush @remote1 status

Going to test this shortly…

Similar Posts:

Testing WP Social Plugins

There are so many of them!
Latest plugin installed is WPGPlus. Let’s see if it actually posts the new blog…
not working so far!

I installed the official Facebook Plugin and set up the app per https://developers.facebook.com/apps. Not sure if it’s working yet. the comments and like buttons are working

Similar Posts:

Apache Reverse Proxy + SSH Reverse Tunnel

Disclaimer: This setup is just a bit crazy, and I wouldn’t recommend it for a production site. Works for me.
I needed to allow some clients to test a web app I’m working on. But I didn’t want to deploy the code to a server for now for different reasons (mainly memory constraints). So the solution was to setup a reverse proxy using apache to my local machine. Check out the code after the break

Similar Posts:

Quick Note

Testing the previous entry, and quick-blogging from the shell

Similar Posts:

    None Found

Email to user@ip address

And I found the answer in this post:

Basically it says:
To mail to IP address, use IP literals, such as user@[]

You might also what to look at the following post for related info as well:

Similar Posts:

    None Found