chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] postgresql tests/run.scm line 17 ff.


From: Peter Bex
Subject: Re: [Chicken-users] postgresql tests/run.scm line 17 ff.
Date: Sun, 3 Mar 2013 11:30:19 +0100
User-agent: Mutt/1.4.2.3i

On Sun, Mar 03, 2013 at 12:05:34AM +0100, Herr wrote:
> Hi,

Hi!

> The following does not look good:
> 
>   (test-assert "reset-connection returns a connection"
>                (let* ((conn (connect '((dbname . test))))
>                       (isconn (connection? conn)))
>                  (reset-connection conn)
>                  (disconnect conn)
>                  isconn))
>   (test-error "disconnect invalidates the connection"
>               (let ((conn (connect '((dbname . test)))))
>                 (disconnect conn)
>                 (reset-connection conn)))
> 
> I suppose in the first test you want to test if the connection is still alive 
> after
> reset-connection, but you only test after connect. Proposed changes: replace 
> test
> last line isconn with (connection? conn)

Yeah, this looks fishy.  Changing the predicate won't help though; it
just checks that the object is a connection structure, which is still
true after a disconnection.  The test is bogus and I've removed it (but
I haven't tagged a new release yet).

> In the second test the return value is from reset-connection, which is 
> problably
> void. 

This test is not verifying the return value, but it's checking that an
error is raised after resetting a nonexistent connection; test-error
does this and ignores the return value.

> Proposed change: replace (reset-connection conn) with (connection? conn).
> Then you will notice that the test fails.

Yeah, because connection? won't raise an error, so the expectation
is no longer correct :)  This test is just fine the way it is.

> I checked this in the REPL: after (disconnect conn) I still got true for 
> (connection?
> conn) but was not able to use it for queries.

Like I said, it just checks the object type, not whether the connection
is still alive.  libpq offers no way to check this.  I could check whether
the connection-pointer is NULL, but it being not-NULL is no guarantee
that the underlying connection is still alive.

Thanks for pointing out the bogus test!

Cheers,
Peter
-- 
http://www.more-magic.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]