From: | Paul Taylor <ijabz(at)fastmail(dot)fm> |
---|---|
To: | Bill Moran <wmoran(at)potentialtech(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Does derby have an embedded Mode like Derby ? |
Date: | 2009-08-04 16:42:32 |
Message-ID: | 4A7864F8.7080908@fastmail.fm |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bill Moran wrote:
> In response to Paul Taylor <ijabz(at)fastmail(dot)fm>:
>
>
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bill Moran | 2009-08-04 16:51:55 | Re: Does derby have an embedded Mode like Derby ? |
Previous Message | Raymond O'Donnell | 2009-08-04 16:37:45 | Re: Line Number |