Hi John:

In message <7867032f-878b-43ed-21fe-3829e7a1b349@jerrykan.com>,
John Kristensen writes:
>John Kristensen added the comment:
>
>On 28/06/16 22:08, John Rouillard wrote:
>> Hmm, mysql IIRC tries to conenct to the db as part of have_backend()
>> or some wrapper around have_backend() in the tests. If it can't
>> connect it skips.
>The bit of code you are interested in is at:
>[...]
>which in addition to checking id the backend exists, attempts to check 
>if the database exists as well, using:
>[...]
>I am not entirely convinced that this extra checking is desirable. If 
>the database does not exist I would prefer that the tests fail loudly 
>rather than skip silently (and potentially go unnoticed).

Except that simply having the backend python libraries in place on
a system doesn't mean you have configured a database.

For example, if I am running roundup using mysql on a system that also
run some other app using postgres, and I want to test the code before
install, it will falsely fail postgres tests possibly obscuring other
failing tests that I care about.

Right now running tests with an explicit -k 'not (mysql or
postgresql)' is required. But is that guaranteed to only disable tests
that require a running copy of those two databases? Could it
accidently trap other tests?

>So my opinion would be that the logic used to determine if the the mysql 
>tests are skipped should be the same as postgresql, not vice-versa.

I see your case, but would argue for the opposite. Would this work?

Add an explicit "is database up" test designed to catch the case where
the back end is configured but there is no db backing it?

So the skip decorators will disable all mysql/postgres tests if the
backend is missing or if there is no db to connect to. However the new
PostgresIsDatabaseUp and MysqlIsDatabaseUp tests would *not* be
decorated. This way the two errors are reported if -k 'not
IsDatabaseUp' (a superset of -k PostgresIsDatabaseUp and -k
MysqlIsDatabaseUp) isn't used.

Does that fill your requirement?

>Maybe this discussion should happen in another issue? or on the mailing 
>list so others can add their opinion?

If you think my proposal needs more thought, or you want to show it to
a larger audience, feel free to toss this issue and msg references on
the list. We can open a new issue if/when this is ready for
implementation.