| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Without this patch the spec tests are configuring sqlite in a manner
that writes the database to a file named ':memory'. This is a problem
because filesystem databases are slower than in-memory databases and the
tests are not cleaning up this file after completing.
The change in 60e78b2d36f23877dc7b50e72578ad123d62c1f0 caused this
change in behavior, likely by accident, because the database connection
string was ':memory:' and the patch changed the string to ':memory'
likely because this looks like a Ruby symbol.
This patch addresses the problem by restoring the original connection
string of ':memory:'
|
|
The activerecord based tests would setup activerecord and rails in a
manner that included stubbing. This made some things behave as you might
want, but caused some manner of getting them to behave the wrong way. By
removing the stubbing, the test cases all work from a clean database.
Another issue occured when one of the tests assumed that no other code
that used its indirection had been run prior to it. The test itself was
very questionable and ended up breaking when the tests were run in a
particular order. The test in question tried to assert that the code
would setup activerecord when it was initialized. Since all of the other
tests relied on this, and that particular behavior did not appear to be
important to the external contract of the class, the test has been
removed.
|
|
|
|
On Unix, we stored the Rails log from our StoreConfigs scratch database in
`/dev/null`, which is reasonable enough - we don't generally care for them,
and that works.
On Windows this is harder because their NUL device is magic, and it is hard to
configure the Rails logs to actually go there. The system loves to interpret
it as a random file relative to the current directory and do the wrong thing
in various test scenarios.
Ultimately, it doesn't matter if we write the logs to physical disk, and we
already had a scratch directory for the physical database - so we can throw
the logs there too.
Just another reason to use a tmpfs to back /tmp, I guess.
Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
|
|
Now that we have a pile of places all trying to do the same setup and
exclusion for SQLite in their tests, it pays to push all that into a central
location and make it uniformly available to all the tests.
This provides a nice, global method that can be invoked by any test suite to
configure the database, and then uses that everywhere that was doing scratch
database setup.
Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
|
