In response to Paul Taylor <ijabz@xxxxxxxxxxx>: > 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. I don't feel like I've missed the point, but I wonder if your definition of "unit" test includes something that I'm not familiar with. We do extensive unit tests that require a DB backend to work. I mean, if you're unit testing the DB client class, it needs a back end to talk to. > 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. And I don't see how that precludes having a DB there that the developer can connect to for testing. We have a DB server specifically for this purpose so that devs can use it to test out their changes before checking code in. More specifically, we have one virtual machine that serves as a dedicated DB server for developer testing. I mean, if it won't work for you, OK. I'm just offering suggestions, and honestly am confused as to what your actual holdup is. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
