Bill Moran wrote:
In response to Paul Taylor <ijabz@xxxxxxxxxxx>:
Bill Moran wrote:
Then replace the DB client class with a class that returns fabricated
data for the purpose of your test.
Won't work because I am writing SQL and I want to test the SQL is correct
Well, be warned that not all alternatives to PostgreSQL will have the
same SQL compliance as Postgres ... so substituting another db backend
is going to be less than reliable.
I hope you don't take these next comments as an attack or anything, but
I think your whole approach to testing is flawed. The fact that tests
are complicated to set up and take a while to run is just life. I mean,
who cares if they take a while to run? Computers don't need to sleep, so
have them run overnight. And any test that's actually comprehensive is
going to take effort to write anyway. Thing is, you'll only be setting
up the PG startup/teardown stuff once, then any test that needs it can
call those functions/scripts/whatever. If you need more computers or a
different OS, then virtualize. All the tools are there for you.
No, I don't take it personally but I think you are missing the point
these are UNIT test not INTEGRATION tests. As such they need to be run
everytime a developer wants to commit some changes to the codebase and
therefore should be quick and unobstrusive to run.
Paul
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
