| Age | Commit message (Collapse) | Author |
|---|
|
Rather than using the system plugins directory for the Turtl server
(which may have plugins that can interfere with the integration tests)
we make a blank plugins directory within the source tree that prevents
such plugins from being loaded.
|
|
The tests that were hanging all had a feature in common - they were
trying to synchronise a file from the server, and this is what the
tests were getting stuck on. For some reason, files will not sync when
the server is accessed from localhost (127.0.0.1) - this was also
noticed when I tried connecting the official Turtl client to the test
server - the file attachment wouldn't sync. What makes this even
stranger is that, although file syncing doesn't work from 127.0.0.1,
it works just fine when the server is accessed via 127.0.1.1 instead.
I'm not sure if this is an upstream bug or if it's a problem with my
personal setup, but for now, I've worked around the issue by manually
specifying 127.0.1.1 as the API/hosting endpoint in both of the test
configuration files.
Now all of the integration tests (except migrate, of course) pass!
|
|
* The integration tests (which actually communicate with the Turtl server) are
now run during the check() step in addition to the regular unit tests.
* Some of the integration tests do not work (authentication error resulting in
the test repeatedly trying and failing to sync with the server) and I have no
idea why, so for now those tests have just been disabled.
* Change the provided server configuration to allow unconfirmed invites, to
allow the respective integration test to work
* I now export the OpenSSL paths directly rather than using vars.mk
* The 'make' calls have been replaced with direct calls to 'cargo'
|
|
* For the core-rs tests, this is simply copying a pre-made file instead of
using sed to patch the template configuration.
* For the server, this is a little bit harder. The server does not support
loading a custom configuration from anywhere on the system, so I copy all of
the server's JavaScript files into a directory within $srcdir, copy the
custom configuration and then launch the server from within $srcdir.
* This has the benefit of ensuring that the servers are running with a fully
custom configuration, rather than using exported variables and sed patches
against a user-controlled config.
|