Bill Moran wrote:
> In response to Paul Taylor <ijabz@fastmail.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
