I really like the idea of the community building a unit testing tool for db application code. I also like the wiki-style in principle -- it engenders collaboration and empowerment. A really strong plus is if the wiki format supports revision history, style guidelines and annotations like wikipedia. If it has true multi-database sql language support then that is a real plus too. Let's also cheer for open source -- thus allowing you to customize it in your own environment.

My job normally is not to test application code, like a stored procedure, but rather to test that concept of a stored procedure works. (I test SQL Server...:w00t:) But I think some of the same lessons apply:

Developers will write great unit tests if they have a low overhead tool. IMHO, this means adopting something that runs in or near the IDE they already use. Visual Studio, NUnit and JUnit give you this. A wiki page will be very different and may be an inhibitor for that reason.

Code re-use looks hard here. I see some signs of a sort of "#include" or "import" but re-using wiki-stlye syntax seems a little hard to me. Also it duplicates the functionality of existing programming languages and environments. Without proper code-reuse you end up with copy/paste code and lack of abstractions where you really need them. Developers may do the same thing 5 different ways. This hurts you when you want to make disruptive changes.

Similar to the last point, a very common operation on test code is to make updates to introduce a new dimension, variable or behavior. I would have some concerns about using a wiki for making such updates. Your bulk search/replace options are very limited since all of your code is locked up in wiki pages. Others might have a better feel for these options than I in this case.

Most importantly, though, I don't see a very rich way to programmatically calculate results. I like to use a "oracle" or a "model" that I trust. Worst case you can persist the results (like this solution does.) But saving your "expected results" can be problematic because of type system differences, subtle changes, "over verificaiton" -- checking more than you intended to -- and most importantly human error! One or two rows may work, but if your functionality needs to be tested at 1000 or 1,000,000 rows this is very impractical. You would then need to do tricks to capture your results and just verify rowcount or an aggregate-- a missing abstraction in this tool.

Like I said, this is a cool idea, and maybe for very limited unit testing it is great. But I would worry about betting too much on such a system and building a large body of unit tests that need to be maintained.