Strange Symphonies The best way to predict the future is to invent it

Related tags

15May/101

Beginning WordPress Automated Testing

I've been a heavy user of WordPress. This blog has been using WordPress for almost the past five years. I've developed multiple plugins and themes for WordPress. Plus I've been a heavy advocate of WordPress for many of my clients work as that is all they really require.

Though I've been a heavy user, I haven't really contributed code to WordPress.

Coming from a Ruby on Rails background, I was familiar with testing. Whilst working with WordPress, I felt a bit insecure that there were no available tests out there.

Lucky for me, with a bit of research I found WordPress did have Automated Testing. When first running the tests, I didn't get 100% success rate. Now this freaked me out.

Soon I learned that sadly not all the tests pass, and the test are outdated. Hopefully there will be plans to update the tests, but in the mean time, here is how to get the tests started.

Dependencies:

  • SubVersion
  • PHPUnit
  • Empty MySQL Database

Installing PHPUnit

WordPress Automated Testing has a dependency on PHPUnit, so we are required to install the package.

Open up your terminal, and as root execute:

pear channel-discover pear.phpunit.de
pear channel-discover pear.symfony-project.com
pear install phpunit/PHPUnit

Installing WordPress Automated Testing

Pull down the Automated Testing code like so:

svn http://svn.automattic.com/wordpress-tests/

This should create a wordpress-tests folder. Now go inside it.

Create a MySQL Database

The WordPress Automated Testing requires an empty database. That means the database should have no records, no tables, nothing.

I simply created a new MySQL Database called wordpress-tests:

mysqladmin -u root -p create wordpress-tests

Now we are almost good to go.

Configuring WordPress Tests

Inside the WordPress Tests directory, copy the wp-config.sample.php to wp-config.php. This configuration is similar to normal WordPress installations. Fill in the necessary details, and you are almost good to go.

Running Your Tests

Once your tests are configured, you can run the tests via executing:

php wp-test.php

Failing Tests

Don't be surprised that some tests fail. Apparently its a normal thing. I messaged the WordPress Testers Mailing List about the tests failing. Judging from the reply I got, apparently its "right".

My test failure rate is:

FAILURES!
Tests: 489, Assertions: 2919, Failures: 136, Errors: 32, Skipped: 18.

Overall it takes about 6 and a half minutes to run.

Conclusion

There you have it, automated testing for WordPress. Hopefully by posting this, more and more people will contribute back to WordPress, and improve the automated testing.

16May/073

Migrating Your Rails Application To Subversion

Note: Once again, a quick, down and dirty solution to moving your Rails application to subversion. The Rails wiki already has this covered, but I find it so messy.

Plan Of Attack

  • Install Subversion
  • Create Rails Application Repository
  • Migrate Rails Application
  • Tips and Tricks
    • Using Plugins
    • Accessing your repository via the Web

Installing Subversion

On Ubuntu Fesity Fawn execute:

sudo apt-get install subversion
[source]

Creating Application Repository

I like keeping my version control repositories in my home directory (ala <code>/home/aizat/repo</code> File). [source] mkdir /home/aizat/repo svnadmin create /home/aizat/repo/railsapp

Note: If you plan to share the repository with other people, or plan to access it via the web, I suggest you move it into some where public. This could be either /repo or /home/repo. You can move your repository later if required.

Migrating Rails Application

Warning: Warning: If you are running any server (webrick or mongrel) shut it down.

Note: Note: This is all executed from the root of your rails application directory.

Move your application to a backup directory.

mv railsapp railsapp.backup

Check out the repository

svn co file:///home/aizat/repo/railsapp

Create the common subversion directories:

mkdir railsapp/{branches,tags}

Copy the backup as the trunk in the repository

cp -a railsapp.backup railsapp/trunk

Move to your trunk directory.

cd railsapp/trunk

Remove temporary files, logs, and other useless cruft.

rm log/*.log
rm -Rf tmp/*

Note: I don't use rake log:clear because it empties the various logs, but leaves the log files there. Similarly I don't use rake tmp:clear so that we can keep the tmp/ completely clean.

Now we remove database.yml as it poses a security risk, because it contains your database information (duh!).

rm config/database.yml

Optional: If you want you can keep an example template, to remind you how the database.yml file looks like. You can grab some from the Rails trunk in their repository.

If you do decide to do this, save it as database.example in your config/

Warning: Similarly if you have other files that store passwords (for example connecting to your mail server) DO NOT store them in your repository. Even if you don't share your repository, because one day you may just do that.

Warning: SQLite specific: If you are using sqlite and the database is stored in your application directory. Remove the database files.

rm db/*.db

Note: Note: If you created documentation for your application via Rake, chances are you don't want it to be saved in your repository

rm -Rf doc/app

Now we go down a level, and indicate we want these directories saved in our repository

cd ..
svn add trunk branches tags

To ensure that your database configuration, logs, and tmp stuff are not stored in subversion, we tell svn to ignore them.

svn propset svn:ignore database.yml trunk/config/
svn propset svn:ignore "*.log" trunk/log/
svn propset svn:ignore "*" trunk/tmp/
svn propset svn:ignore app trunk/doc/
svn propset svn:ignore plugins trunk/doc/
svn propset svn:ignore api trunk/doc/

Note: SQLite specific: Let's ensure that the database is not stored in subversion.

svn propset svn:ignore trunk/db/*.db

Your rails setup should now be prepared to commit to the repository.

svn ci -m "Initial commit"
svn update

Note: After the initial commit, I remove the railsapp/ directory, and checkout again, like below. This simplifies the directory structure for me.

You are now good to go, and can checkout the repository anytime via

svn co file:///home/aizat/repo/railsapp/trunk railsapp

Tips and Tricks

Using Plugins

You can now keep your plugins up to date with subversion as well. When installing a plugin, use the -x flag. Example:

./script/plugin install -x acts_as_taggable
[/block]

Accessing your repository via the Web

Let's first install Apache. [source] sudo apt-get install apache libapache2-svn

Now the big question is. Where did you create your repository, because Apache needs access to it. If you've created your repository in ~/repo, how do we move it? Let's assume you'll be moving it to /home/svn.

So lets create the repository location, and create the necessary groups

sudo mkdir /home/svn
sudo groupadd svn
sudo adduser aizat svn
sudo adduser www-data svn
sudo chown -R www-data:svn /home/svn
sudo chmod -R 0660 /home/svn

Note: In the third line sudo adduser aizat svn, replace 'aizat' with your actual username. You may need to login, and out to update the groups you are in.

So we'll prepare the repository for access by Apache.

svnadmin dump /home/aizat/repo/railsapp &gt; /home/aizat/repo/railsapp.dump
cd /home/repo
svnadmin create /home/svn/railsapp
svnadmin load /home/svn/railsapp &lt; /home/aizat/repo/railsapp.dump

To ensure that no one can access the repository, we will use simple authentication.

htpasswd /home/svn/railsapp.passwd aizat

Open up /etc/apache2/mods-enabed/dav_svn.conf File, and insert:

<Location /svn/railsapp>
  DAV svn
  SVNPath /home/svn/railsapp
  AuthType Basic
  AuthName "Rails Application"
  AuthUserFile /home/svn/railsapp.passwd
  Require valid-user
</Location>

This will make your subversion repository accessible via http://example.com/svn/railsapp.

So you can check out your code ala:

svn co http://example.com/svn/railsapp/trunk railsapp

Note: Pay Attention to the SVNPath and AuthUserFile those should be set accordingly to your setup. There is also support for ACL, but I won't cover that now.

Warning: You are still vulnerable to man in the middle attacks, but it is good enough in some cases. To ensure another layer of security, it is recommended to use SSL. Easy creation of SSL is currently broken in Ubuntu Fesity Fawn. There is the traditional method, but that is really long, and really goes out of scope of this post. I'll cover it if people really want it.

Subversion Resources

If you are new to subversion, have a look at the book Version Control With Subversion. It's freely available online in multiple formats (HTML, PDF, DocBook).