Re: [Haskelldb-users] Release

[Bjorn B. <bri...@cs...>]

On Jul 17, 2006, at 1:14 PM, Matthias Radestock wrote:

> Bjorn Bringert <bri...@cs...> writes:
>
>> I think that some sort of test suite would be very nice to have
>> before a release, but that might just be my personal opinion.
>
> IMHO the test suite is *essential*. HaskellDB is quite a complex =20
> library
> and changes in one area can have far-reaching and non-obvious
> consequences. In absence of a large user base, a reasonably
> comprehensive test suite is crucial for tracking down bugs. I was
> horrified when I found out that the current test suite had
> bit-rotted. It means that all recent changes are highly suspect and =20=

> will
> have most likely broken something somewhere.
>
> Bjorn, do you know when the test suite was last run successfully? Then
> we could take a look what changes were introduced since then and add
> test cases for those. Ideally we'd also do coverage testing to =20
> determine
> what other tests we should add to get a reasonably good coverage of =20=

> the
> library.
>
> One added complication is that the test suite should be run against a
> variety of db backends, in order to identify db-specific code that has
> crept into the generic code base, and bugs in the db-specific code
> itself.

I don't think that it would be too hard to get the current tests =20
running again, but they were never that good:

- There has never been a time when all of them worked on all back-=20
ends, because of back-end incompatibilities.
- The coverage is probably quite poor.
- Many of them don't check their outputs, they mostly just test that =20
HaskellDB doesn't generate bad SQL or crash in some other way.

Some ideas for getting a good test suite together:

- Design a test database and write DBInfo for it.

- Use DynConnect for database connections. Extend DynConnect to =20
support all driver (missing HDBC drivers at the moment)

- Have some way for the user to provide connection parameters to all =20
the database back-ends to test with.

- Use HUnit, and maybe even QuickCheck.

- Maybe the FlatDB [1] backend could be used as a reference. It's a =20
simple database back-end whose query language is HaskellDB's internal =20=

PrimQuery type.


One of the reasons that this hasn't been done yet is that the back-=20
end incompatibility problem is so frustrating. But a test suite would =20=

be a good way to identify the things that need to be taken care of by =20=

any back-end specific SQL generation.

I can try to get a test framework together. Are there any volunteers =20
who would like to contribute test DB layout, data, unit tests or =20
QuickCheck properties?

/Bj=F6rn

[1] http://www.cs.chalmers.se/~bringert/darcs/haskelldb-flat/