Re: [HACKERS] Inadequate traces in TAP tests
От | Stephen Frost |
---|---|
Тема | Re: [HACKERS] Inadequate traces in TAP tests |
Дата | |
Msg-id | 20170320142620.GL9812@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Inadequate traces in TAP tests (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Inadequate traces in TAP tests
|
Список | pgsql-hackers |
Alvaro, * Alvaro Herrera (alvherre@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Andrew Dunstan (andrew.dunstan@2ndquadrant.com) wrote: > > > ISTM that the test setup and breakdown code, both in individual tests > > > and in PostgresNode.pm should be liberally sprinkled with diag() calls > > > to make it easier to narrow down errors.. > > > > While I'm generally in favor of adding diag() info into the testing for > > when things go wrong, what I don't want to do is increase the amount of > > output that these tests produce without good cause. I really wish there > > was a "quiet" mode for the TAP tests which didn't report anything when > > things are 'ok'. > > That's diag's idea; you use it like > "ok() or diag('failed because of snow')". > so nothing is printed unless there is a problem. You're not supposed to > call it unconditionally. That seems reasonable then. > Something that would probably be helpful would be to put the server log > lines corresponding to the failure in diag(); for example we could keep > the log file open, do a seek(SEEK_END) just before running the test, and > reading from that point onwards; probably stop reading after 5 lines or > so. They wouldn't be output unless there is a failure. (Of course, > this'd have to be done in the harness, not the test itself, to avoid > cluttering already ugly individual test files.) Agreed, this should be in the harness. Is there any hope of getting a "quiet" mode, where all the "ok" lines aren't printed when things work..? Thanks! Stephen
В списке pgsql-hackers по дате отправления: