pgTAP 0.21 Drops
I just dropped a new version of pgTAP following a few marathon hack sessions
since my talk at PGCon (movie here, BTW). Actually, the new
performs_ok()
function came about as I wrote the presentation, but all the
rest came on the flight home and in the few days since. Not sure when I’ll hack
on it this much again (it’s getting a bit big at 5,758 lines of PL/pgSQL and
SQL).
Overall I’m very happy with this release, as it adds a lot of new assertion functions. In particular, I added a slew of functions that test that the objects in a given schema (or visible in the search path, if you prefer) are exactly the objects that should be there. This is useful for a couple of things. For one, Norman Yamada, in his PGCon talk, mentioned that his team was using pgTAP to compare database objects between replicated databases. I like this because it’s a great example of using pgTAP for system testing, rather than just unit testing as I’ve been advocating. See, pgTAP can be used for any kind of testing!
Another use for these functions is in a large organization where many different
people might be making changes to a schema. In this scenario, you might have
application developers adding new objects to the database (or dropping objects)
without necessarily informing the DBAs. Using, for example, tables_are()
and
functions_are()
and continuous testing, the DBAs can see when objects have
been modified by the developers. Even better, if the developers are running the
pgTAP tests themselves (as they should be!), they will be reminded to add new
tests for their changes when the existing tests notice that things have been
added or dropped and thus fail.
Beyond that, I added a bunch of new functions for testing functions and a number of other goodies. Check out the release notes for all the details.
With these changes, I’ve finished nearly everything I’ve thought of for pgTAP.
There are only a few sequence-testing functions left on the To Do list, as well
as a call to add a throws_like()
function, which I’ll throw in soon if no
one else steps up. Beyond these changes, I have a few ideas of where to take it
next, but so far I’m kind of stumped. Mainly what I think should be done is to
add an interface that makes it easier to compare relations (or result sets, if
you prefer). Epic does this by allowing query strings to be passed to a
function, but I’d really like to keep queries in SQL rather than in SQL strings.
I’ll be giving it some more thought and will post about it soon.
Looking for the comments? Try the old layout.