Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PgTAP: Unit Testing for PostgreSQL

pgtap.org

Post reply on HN
Print view View original

1–10 of 22 posts

Re: PgTAP: Unit Testing for PostgreSQL

#2

Post by rectang »

I've always loved TAP-style testing over xUnit because it gives me more information in the event of failure: instead of bailing out of a test function as soon as an assertion fails, TAP continues on, providing more failures and more output. When the tests were run on a system you don't have access to, that can mean the difference between being stymied and successful debugging. Sure, you can code up xUnit tests to meet that requirement but it's not idiomatic.

Glad to see PgTAP is still going strong!

Re: PgTAP: Unit Testing for PostgreSQL

#4

Post by mcfunley »

I was at Etsy when this was being built by a consultant, ostensibly for us to use to test our morass of stored procedures in perpetuity. Early on, someone got some bad advice and thought you were safe from sql injection if you wrote your sql inside stored procedures. This misconception got wildly out of hand.

We stopped writing sprocs and migrated to MySQL over many years instead. I'm happy with the decision. The database isn't a good place to put things that need extensive unit testing.

Or at least it isn't if you're a giant consumer-facing website. YMMV.

Re: PgTAP: Unit Testing for PostgreSQL

#5

Post by ghufran_syed »

Does the use case for this maybe depend on your application language and testing facilities? We are comfortable writing sql where it offers an advantage over the alternative, but I can't see what benefit PgTAP offers for our situation (but very willing to be persuaded).

We have a rails app backed by postgres. We routinely write database migrations in sql (activerecord doesn't seem to offer much advantage here), and write plpgsql functions to enforce data integrity across tables that we feel we can't do as well in Rails. However, we test our plpgsql functions using rspec / factorygirl / rails ruby code and find it's much easier to read, write and run these tests than it would be in sql. Maybe it would be different from a different application language? Or are there some specific types of tests that cannot be done from application code?

Re: PgTAP: Unit Testing for PostgreSQL

#7

Post by zaphar »

rectang wrote: post #2

I've always loved TAP-style testing over xUnit because it gives me more information in the event of failure: instead of bailing out of a test function as soon as an assertion fails, TAP continues on, providing more failures and more output. When the tests were run on a system you don't have access to, that can mean the difference between being stymied and successful debugging. Sure, you can code up xUnit tests to mee…

Me too.

TAP output encourages longer more informative failure messages as well as more comprehensive output due to exceptions not being the default method of expressing test failures.

Most xUnit style tests allow you give more informative messages and some even provide alternatives to Assert for expressing failures that allow you to collect much more information about the state of a failing test. But the API's and culture around xUnit style testing don't encourage it so almost no one writes them that way.

Re: PgTAP: Unit Testing for PostgreSQL

#8

Post by pyre »

mcfunley wrote: post #4

I was at Etsy when this was being built by a consultant, ostensibly for us to use to test our morass of stored procedures in perpetuity. Early on, someone got some bad advice and thought you were safe from sql injection if you wrote your sql inside stored procedures. This misconception got wildly out of hand. We stopped writing sprocs and migrated to MySQL over many years instead. I'm happy with the decision. The dat…

Why the migration to MySQL rather than just migrating away from the stored procedures?

Re: PgTAP: Unit Testing for PostgreSQL

#9

Post by mcfunley »

pyre wrote: post #8
mcfunley wrote: post #4

I was at Etsy when this was being built by a consultant, ostensibly for us to use to test our morass of stored procedures in perpetuity. Early on, someone got some bad advice and thought you were safe from sql injection if you wrote your sql inside stored procedures. This misconception got wildly out of hand. We stopped writing sprocs and migrated to MySQL over many years instead. I'm happy with the decision. The dat…

Why the migration to MySQL rather than just migrating away from the stored procedures?

We hired some key employees from Flickr who knew a particular MySQL sharding strategy really well. Postgres would have worked fine, just not the way we were using it back then.

Re: PgTAP: Unit Testing for PostgreSQL

#10

Post by elchief »

mcfunley wrote: post #4

I was at Etsy when this was being built by a consultant, ostensibly for us to use to test our morass of stored procedures in perpetuity. Early on, someone got some bad advice and thought you were safe from sql injection if you wrote your sql inside stored procedures. This misconception got wildly out of hand. We stopped writing sprocs and migrated to MySQL over many years instead. I'm happy with the decision. The dat…

Ya PostGIS is dumb and worthless. You should only use your db as a dumb data dump. You shouldn't even bother with keys.
Post reply on HN