Someday, your super website starts to look old and needs to be more then just updated.

You hire a designer and suddenly you would like to be able to test the new site with all your content.

Until now, your only solution was to change the Skin used in a special section and stay there for testing. This is bad because what you need is to see the complete site as it would be.

dev skin

This is exactly what the new implementation of the “development Skin” does: show your site with another skin, bypassing the node’s settings. The selection appears on the dev box.

rescue skin

This feature can also be used as a rescue solution if you totally broke your site: simply call the ”/rescue” url and you will be able to use your site with a hardcoded rescue skin.

I am building the xml API for Zena (damn simple since we only have 1 model through which everything passes: Node). But it’s been a while now that I cannot write code without writing the tests and so I wanted to test my NodeResource.

How to test ActiveResource ?

You can either launch you application and then start your tests with “localhost” but… you cannot use transactional fixtures since you do not share the connection to the database. This means that apart from read tests it is pretty useless.

Use Integration tests !

I have written a MockConnection that makes your ActiveResource share the connection with the integration test. This means that when your NodeResource does a :put, it’s actually your integration test that executes the “put” method with all the xml data and such.

If you want to reuse the code:

• module: Zena::Integration::TestCase
• usage example: XmlAPITest

Since fixing tests is not so much fun, I thought I’d spend a couple of hours to fix the popup problem:

If you edit a page with a popup and need to navigate to another page or tab (find a reference in Wikipedia, get a link to some site, check spelling, ...), the popup disappears behind the last window. To continue editing, you have to:

1. Go back to article window
2. Find the popup editor
3. Manage to have both in sight

This is the past !

Thanks to Sébastien Gruhier who built the excellent prototype-window library, it was a joy to implement and I could spend some time tweaking the window style:

PS: This change has been made on the 1.0 branch: a nice feature to help motivate the integration tests ;-)

This is an evolving post to show the unit tests fixing progression.

1. At the beginning, the errors are high because of the calls to the legacy ‘v_title’ and content methods which do not exist anymore (replaced by property).
2. Fixed Version tests.
3. Fixed Template tests.
4. Renamed Node.name to Node.node_name to avoid confusion with Contact.name or other uses. (Error peak)
5. Fixed (and refactoring) of Document and Attachment tests.
6. Started fixing helpers testing (had to rewrite controller mockup and such), did some review of the ‘node_name’ change consequences.
7. Fixing Node tests (not all done) and fixed Workflow tests.
8. Implemented Roles and Enrollable (dynamic role activation on write)
9. Making Secure, VersionHash and Workflow tests pass.
10. Fixed Relations, QueryNode, Image and Co
11. Fixed typos in tests, all pass except 1 test (passes alone, but not with others): locale issue
12. Fixed last test (“strftime” was depending on ENV['LANG']).

All the unit tests pass now !

conclusion

8%

This is the test count growth, mostly due to the refactoring of large tests into smaller tests by using shoulda.

a graph is good

Having a graph with real numbers was very helpful to see that work was advancing even though I felt things were going worse (see bump in the graph).

1989 tests, 3909 assertions, 388 failures, 77 errors

This is the current number of passing/failing tests in Zena’s full test suite and gives an idea of the work left.

Integration (aka Zafu) bug fixing tests can be followed in this post.

The refactoring to use rubyless in the templates and improve custom attributes handling (property) that started in autumn 2009 was quite big and now many tests in the 1.0 branch fail.

Such important changes are hard to endure because there is a time when the feature set and stability of the new development branch (1.0-pre) goes way below the current stable branch (master = 0.16.x) and moving all the codebase back up (3 years of production ready code enhancements) takes time.

So this is a post to ask for any kind of help regarding this bug fixing task (30% unit test failure).

If you cannot help with the bug fix…

...but think Zena is an interesting project, just drop us a line of encouragement as a comment on this post !

If you can help fix the tests

Please fork http://github.com/zena/zena.git and use rake test:units to see the list of failing tests.

You can use gold to ease Push and Pull operations with git.

During gold setup:

reviewer email = gaspard(at)teti.ch
current gold branch = 1.0-pre (not master)

If you do not want to use gold, you have to track the “1.0-pre” branch by hand:

git clone http://github.com/[YOUR_NAME]/zena.git
git remote add zena git://github.com/zena/zena.git
git fetch zena
git checkout --track -b gold zena/1.0-pre

Thanks for any feedback.