Jeff’s Austin Blues

For a variety of technical reasons, most of the full-text search engines available for Ruby on Rails do off-line indexing. (Changes to the indexed tables are added to a queue that is processed in a cronjob, i.e., changes do not show up immediately in indexes). Examples of off-line indexing search engines are Xapian, Sphinx, and Hyper-Estraier. I think all three retrieve records for indexing directly from the database. This causes problems in testing.

To speed up testing, Rails does not commit any changes to the database made from individual tests. The lot is discarded in a rollback of a transaction started at the beginning of each test. Fast, but programs outside the Rails stack do not see the changes. Even after I jumped through hoops to run the index update program within a test.

Loading the fixtures, indexing them, and then running the tests works if fixtures are all the tests search for. In MySQL, the statement “SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED” will work around the limitation, but it’s non-portable and I’d have to maintain some hacked third-party code. No thanks.

According to the docs xhr is an alias for xml_http_request, a wrapper for the post, get, etc. methods for testing that flags a request as an AJAX style request. However, for at least some versions of Rails (I’m using 2.1), the xhr alias is broken. Using it gives the following error: ArgumentError: wrong number of arguments (4 for 3). The solution is to use xml_http_request, details here.

Several years ago I was involved in developing a Web app server that allowed the apps to be written in one language, HTML/XHTML/XML with a few extensions. I had been working with PHP and had reached the point where dealing with two languages intermixed (HTML and a C-like programming language) was a pain and was running out of steam. Just one language had a lot of appeal. After a lot of work by several people, we decided that maybe one language was a great idea, but this wasn’t the one.

I am now working with Ruby on Rails. It is several languages, Ruby, HTML/XHTML, and possibly Javascript (for AJAX). It is fun, but I noticed that I write only the simplest bits of HTML. The fancier bits are generated by Ruby code. And I am not writing any Javascript, just Ruby code that generates the Javascript. It’s getting closer to one language, and not the one I expected.

From reading the change log and just the timing I thought that RSpec 1.1.1 worked with Rails 2.0. A few test failed but some of them were clearly bit rot, tests that had not been updated as I added and changed functionality. However others were more problematic. One of the fixtures is not loading at all. It’s unclear how it is different from the others. Running the tests twice in a row gave different failures. Running the tests with rake and with script/spec gave different failures.

One problem I just noticed with RSpec is that is hard or impossible to run individual tests within a file or even individual spec files. I don’t currently have any view tests or stories, so I plan to follow the examples and write a few. That should tell me if I am using obsolete features or what.

TagFlow has been accepted as a project on RubyForge. It is just the project default page(s) for the moment, but it exists. Now comes the work of uploading the code, building Web pages, starting discussions, etc.

TagFlow is a very lightweight, flexible, and multi-lingual task/item/issue management system. It is an attempt to build something agile and adaptable to different styles. It uses tags to indicate priorities, task types (e.g., usecases, bugs, documentation), assignment to people, etc. It is nearing release 0.2. It has been hosting it’s own task-list/workflow since release 0.1.

For the release 0.2 of my current project, TagFlow, I intend to have complete Test::Unit and Rspec suites. I have been building the Test::Unit suite as I went along, so there isn’t much left to do. Last week I added the last of the features for the release and started refactoring the code, readying it for public release. Earlier this week I completed the refactoring and started building the Rspec suite. I probably will maintain both for a release or two and then settle on one approach.

I’ve found a couple of good tutorials, the RSpec project documentation and “Developing a Rails model using BDD and RSpec, Part 1″ by Luke Redpath. The latter is over a year old and the syntax is different now, but the ideas are good. I am starting to like the BDD/RSpec approach. Since the tests are run in the order in the file, each test can not test for behavior already tested. For example, if a test search should find exactly three matches, a prior test can test that searches succeed and this behavior check can skip that and just test for three matches. Whereas in the Test::Unit approach, the more complex test is essentially the simple test with an additional test. Typically tests have a half dozen asserts, the last one is what is actually being tested and the rest making sure that the last test is meaningful.

RSpec is still under rapid development and there isn’t yet integration (cross-controller) tests in the trunk. Test::Unit is fairly complete and stable. However, integration and experimental story support are in the RSpec development tree. Hopefully they will be usable by the time I’m ready to use them.