Related tags
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.
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>). [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 > /home/aizat/repo/railsapp.dump cd /home/repo svnadmin create /home/svn/railsapp svnadmin load /home/svn/railsapp < /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
, 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).
