On 09/15/2014 07:08 AM, cowwoc wrote:
On 15/09/2014 9:39 AM, Adrian Klaver wrote:
Not exactly. Each test is responsible for populating its own schema
(creating tables, inserting data). The main purpose of using temporary
schemas is to ensure that each test runs in isolation so that data from
other tests cannot influence the outcome of the test. This ensures test
execution/results are 100% reproducible.
So the tests may or may not have anything to do with the existing test
database?
Hi Adrian,
I don't understand what you mean by "the existing test database". In my
mind, tests have nothing in common with each other. They are meant to
execute in complete isolation of each other.
From your second post:
" 1. I'm already planning to run unit tests against a separate (but
identical) database than production, so there's no danger of wiping
out the production database.
2. I need to create a new temporary schema per test, and run 4-10 of
tests per second. I'm guessing this wouldn't perform well using
"pg_ctl".
"
I took that to mean you want to create the temporary schemas over an
existing test database.
It sounds to me like you thought I create a test database once
(containing the tables, functions, triggers used by tests) and then
running tests against that one at a time. In actuality, each test is
expected to create its own tables, functions, triggers and execute
concurrently and in complete isolation with other tests.
One of the requirements is that if someone kills the process running the
unit tests, it can't leave behind any dangling schemas. I expect all
test data to get dropped automatically when the connection is closed
unexpectedly, so DROP DATABASE won't do.
I would think a DROP DATABASE IF EXISTS, CREATE DATABASE at the
beginning of the test would handle that.
This would only clean up the next time tests are run. I'm looking for a
cleanup at the end of the tests, not the beginning.
As well, the fact that I have concurrent test execution means that I
don't know how many databases/schemas there are to drop. I guess I could
scan the database metadata for all test-related schemas but clearly this
isn't as clean/fun as having temporary schemas in the first place.
I will admit to not being a testing expert, but from what I have done,
I know test suites have setup and teardown sections.
Would this not work?
My previous suggestion was a fall through for the case you mentioned
where a process is terminated outside the test.
And lastly, remember that we want these tests to run as fast as
possible. TEMPORARY/UNLOGGED tables are ideal from that point of view
but I can't specify TEMPORARY/UNLOGGED because the unit tests and
production code must share the same SQL script.
I can see that being possible. There will always be some difference
though as unit tests are not the same as rolling out production scripts.
The test code will need to include the actual test, unless I am missing
something obvious. Entirely possible:)
Gili
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
