Considering the number of agile folk who use emacs, it's pretty surprising how difficult it is to find code for automated testing of elisp. There's plenty of stuff for running tests in other languages, but I was only able to find one Emacs Lisp specific testing library.
Unfortunately as I look at the internals of regress.el, it's clear that it's written by someone very unfamiliar with everyday Lisp idioms:
(while suites (setq suite (car suites) suites (cdr suites)) (if (and (car suite) (not (stringp (car suite)))) (setq description "Untitled test suite") (setq description (car suite) suite (cdr suite)))
Apparently the map function is unfamiliar to the author. It's strange, because this is a really useful library. It works very well, and it's quite well documented. (It was well-tested, go figure.) I've made a few improvements to it so the test results are more readable, but I'm thinking I might just want to rewrite it. This is partially because the internals are so bad, partially to make it more xUnit-ish and focused on TDD rather than regression testing, and partially just because it would be a good exercise in emacs lisp.
We'll see how that goes. It should be fun, but it may be foolish to put off improving Rails support for the time that this will take to implement. Then again, if my past experiences with elisp are any indication, this will take a lot less time than it would seem like it should up front. Also, having this in place while writing the Rails support modes would probably smooth things along quite a bit.
Speaking of Rails support, I've improved RHTML-mode rather significantly in the past few days. There is still one immensely irritating bug that is getting in the way, but on the whole it's coming along quite nicely.