Tested against ejabberd's failing installation. The entire test suite
gets marked as failed if the application installation fails.
Fixes#1902#1895
Signed-off-by: Joseph Nuthalapati <njoseph@riseup.net>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Ensuring that load_cfg fixture is ordered first will ensure that configuration
is properly restored after test and that changes in other fixtures take effect.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
When deleting connections after editing, sometimes the connection is not found.
Wait until the connection settles down to avoid connection not found errors
during cleanup. Seems to work for now but still not the best way to handle this.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
The file is not meant for human reading. The comments are already part of the
code.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Read configuration files from three different locations.
/usr/share/freedombox/freedombox.config, /etc/plinth/plinth.config and
/etc/freedombox/freedombox.conf. Later listed has higher priority.
- Provide backward compatibility for /etc/plinth/plinth.config files. With lower
priority than /etc/freedombox but higher priority than /usr/share/.
- Read sorted files from config.d directories with the same suffix as original
configuration file. Parse them by priority. This allows administrator/programs
to drop in configuration bits without worry about editing files.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Avoid a top level source code file.
- Makes it clear that the configuration file is only meant for development
purposes.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Read from /etc/plinth, /usr/share/plinth and /var/lib/plinth.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- The configuration module defaults to values in the production configuration
file.
- If the file is found, it is read and the read values overwrite the defaults.
If the file is not found, no error is raised. This allows us to not ship the
configuration file. User may create the configuration if they want to change the
defaults. This eases upgrades when configuration is edited. This also make
FreedomBox robust to deployments where /etc/ is not populated by default such as
OSTree. It is also a good practice for daemons as followed by the likes of
systemd.
- If the file partly populated only the values read override the defaults and
the remaining values don't change. This allows the user to write simpler
configuration file.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
We are currently using django.utils.http.is_safe_url which is a private method
and may break API anytime. Replace it with similar but limited implementation.
Tests:
- Unit tests.
- Dismiss a notification and the redirect to the same page happens properly.
- Logout, goto to home page or login page. Change the language and it will
redirect back to home page or login page appropriately.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
The request variable is not available when a custom template is used to render a
notification. Fix this by passing the template rendering context additional
request variable.
Closes: #1887.
Tests:
- Reduce the version number in data for 'upgrades-new-release' notification
in the plinth_storednotification table in the DB. Start FreedomBox. New release
message will appear. Go to page other than home page. The dismiss button has
next= parameter filled properly with current URL. Dismiss the notification and
notice that page URL stays the same.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
The fixture splinter_browser_load_condition already waits until a page
is loaded.
Signed-off-by: Veiko Aasa <veiko17@disroot.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
- Use a submit() function to wait for a update when visiting app pages.
This prevents failures on pages which have custom javascript,
including the backup app. Those errors are more common if the server
hardware is slower.
- Remove unnecessary wait_for_page_update() as submit() already waits
for a page update.
Signed-off-by: Veiko Aasa <veiko17@disroot.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Catch exeptions if web server restarts on form submit.
Signed-off-by: Veiko Aasa <veiko17@disroot.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
- By waiting for one app to finish installing before trying to install.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Splinter/selenium have implicit and explicit waiting time. Implicit wait time
will make every negative lookup wait for about 3 seconds before it actually
fails. Because we ensure missing elements in quite a few places, this introduces
many 3 seconds wait periods during testing. Remove it instead rely on explicit
waiting whenever needed.
- Explicit wait time is only used during explicitly requests waiting conditions.
In a loop the API waits for a maximum of timeout period until a given condition
is satisfied. Each time the condition is checked, it goes into sleep for
explicit wait period amount of time. This is typically a second or so. Since we
are impatient, make it 0.1 instead.
- Also make sure that whenever a page is visit()ed, we automatically wait until
the page is fully loaded by overriding the splinter wait condition. Otherwise,
we will need to introduce waiting code in a lot of places.
- Using document.readyState == complete is a better check to ensure that a page
is fully loaded. If we proceed with the page 'loading' or 'interactive' state,
we will have to change a lot of code to make it wait.
- Handle Apache restarts when waiting for page load. The error page apparently
is never reaches document.readyState == 'complete'. So, if an error page is
encountered, always reload.
- While waiting for installation, ensure that we atomically check that page has
loaded fully and the installation progress is not being shown. Otherwise, there
would be race condition due to installation page refreshing itself.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Fix the condition for checking if we are on progress page by ensuring that the
page is loaded fully before checking if it is that progress loader. Avoid a race
condition writing a single atomic JS script to check both conditions.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- When subscribe button is clicked in subscribe dialog, the dialog does not
close immediately. Wait until it closes or error appears.
- When a feed is added, the feed list refreshes and during that time, it is not
possible to click on the feed expand button. Wait until it can be clicked.
Extend the eventually() method to wait on exceptions and not just false values.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Move non-reusable app specific step definitions and helper methods into
<app>/tests/test_functional.py.
- Merge reusable helper methods into plinth.tests.functional
- Merge reusable step definitions into plinth.tests.functional.step_definitions
- avahi, datetime, ikiwiki: Reuse common methods to avoid repetition. Avoid
mapping from app nicknames to actual app names.
- deluge, transmission: Make a copy of sample.torrent for each app to avoid
clogging common place.
- Implement functional.visit() to simplify a lot of browser.visit() calls.
- Ensure that name of the mark on functional tests for an app is same as name of
the app. This will help with predicting the mark when running tests for a
particular app.
Tests performed:
- Run all functional tests.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Joseph Nuthalapati <njoseph@riseup.net>
- Add pytest hooks to ignore all functional tests if pytest_bdd is not
installed.
- Update pytest hooks to skip tests in file named 'test_functional.py' if
--include-functional argument is not provided.
- Move functional_tests/install.py into plinth/tests/functional and update
reference in Vagrantfile.
- Move scenario files into individual app folders. Rename them after the app
they are testing. Merge TODO items listed in todo.org into corresponding feature
files.
- Add test_functional.py in each app to build tests from the features file using
pytest_bdd.
- Move all step_definitions, support and data into plinth/tests/functional/.
Include all step_definitions from conftest.py. Update to relative imports
instead of absolute imports.
Tests performed:
- Run py.test-3 --collect-only shows all functional tests and lists 574 tests.
No errors show that name of feature files are correct. The number says that all
functional test features are included.
- Remove pytest_bdd (or modify the import name) and run py.test-3 --collect-only
skips collecting all functional tests and shows only 300+ tests.
- Run functional tests for a few apps with py.test-3 --include-functional -m
app. For storage, deluge.
- Run unit tests with py.test-3. Functional tests are listed by skipped.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Joseph Nuthalapati <njoseph@riseup.net>
Also don't require updating all the common properties of a connection when
updating only some properties such as 'autoconnect'.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Network Manager client fetches the basic information from Network Manager,
caches it and updates the cache whenever it receives the signal. So, create only
a single instance of it and reuse it. Reusing from different threads is
apparently fine because the underlying DBusConnection is a singleton[1] that is
meant to be used from multiple threads.
The glib main loop context that is related to the client must run even after the
network manager client object goes away[2]. So, create the network manager
client instance from a thread that continues to run the glib main thread.
This fixes an infrequent crash when accessing network manager page. The problem
was reproducible from very early version of Network Manager and FreedomBox.
However, in more recent versions of NetworkManager 1.20 with recent DBus changes
in FreedomBox, the problem is more prominent. The problem reduces to a simple
warning in NetworkManager 1.22.
Closes: #1724Closes: #382
Tests:
- Reproduce the problem by accessing the networks app index page repeatedly.
- Create a simple test case file to reproduce the problem and ensure that the
fix works there.
- On Network Manager 1.20 repeatedly access the networks app index page and
create/delete/activate/deactivate/show connections.
- On Network Manager 1.22 repeatedly access the networks app index page and
create/delete/activate/deactivate/show connections.
Links:
1) https://developer.gnome.org/gio/unstable/GDBusConnection.html#g-bus-get-sync
2) https://developer.gnome.org/libnm/stable/NMClient.html#nm-client-get-main-context
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Use the API to skip diagnosing apps that don't implement diagnostics.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
A class name that starts with 'Test' is considered for test case collection
resulting in the following warning:
plinth/tests/test_app.py:28
/home/bunny/work/freedombox/plinth/plinth/tests/test_app.py:28: PytestWarning:
cannot collect test class 'TestApp' because it has a __init__ constructor
class TestApp(App):
Since this class does not contain test cases itself, rename it.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
When tmpdir fixture is used, the tests run in a separate directory instead of
command execution directory. Any tests that take the current directory and
assume that it contains files will fail. Fix this by taking the path relative to
test module instead.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
