VuFind® uses a set of Unit Tests to check for problems as the software develops and evolves. Automated tests are generally the preferred way to test software, since they are automatic and repeatable. However, sometimes humans can detect problems in areas where automated tests cannot (like aesthetic changes), and sometimes manual testing is useful as a lead-up to developing automated tests. This page contains notes intended to be helpful for manual testers.
It is a good idea to test the interface in multiple browsers to check for display inconsistencies and Javascript incompatibilities. We are most concerned with compatibility with the current generation of browsers, but compatibility with earlier versions is desirable when possible. Recommended browsers to test:
The automated test suite typically runs in Chrome, so doing manual testing in other browsers is a good way to potentially uncover browser-specific issues.
Some general patterns to follow when testing new features:
If you find something that breaks, please don't just fix it – also build an automated test to prevent regressions!
VuFind®'s test suite is not able to connect to third-party systems. While it can simulate these interactions for testing purposes, if third-party systems actually change their interfaces, the test suite will not be able to detect problems. There is no way around this – we do not own copies of every Integrated Library System ever published, or have subscriptions to every third-party resource. Therefore, user testing of integrations that they have access to is valuable to ensure that our code remains up-to-date and relevant.
Some areas of code that benefit from this type of testing:
If you test and discover that something is not working, please open a JIRA Ticket to report the problem.
VuFind® has a lot of optional features which are not immediately visible. This section of the page provides quick steps for turning on optional features so that you can test and evaluate them. This is intended to be used in combination with VuFind®'s standard test environment, which you can learn how to set up by watching the Setting Up a Test Environment video or reading the unit testing page.
If you want to test multi-column search, you will need to customize combined.ini, since the default configuration includes examples that are unlikely to work in most environments without additional configuration. For testing purposes, you can override the third-party service examples with the Search2 backend to simulate results. Just create a local copy of combined.ini and change the [Summon] and [EDS] section headers to [Search2:Summon] and [Search2:EDS] respectively. When you perform a search, all of the columns will show results from the Solr index, and there is likely to be overlap between the columns, but for the purpose of testing multi-column functionality, this should not matter too much.
VuFind® supports indexing data in a specially-formatted way to enable facets to be displayed as a hierarchical tree. The test suite sample data includes a hierarchical facet field which is disabled by default but can be turned on for testing by following these steps:
hierarchical_facet_str_mv = Hierarchy
hierarchical[] = hierarchical_facet_str_mv
exclude = *
or exclude = hierarchical_facet_str_mv
to the [Results_Settings] section of facets.ini. It is recommended to test both with and without this setting.orFacets = *
or orFacets = hierarchical_facet_str_mv
to the [Results_Settings] section of facets.ini. It is recommended to test both with and without this setting.hierarchical_facet_str_mv = Hierarchy
at the top of the [HomePage] section of facets.ini. This should make the tree appear at the /Search/Home URL of your installation.VuFind®'s “library cards” feature allows a single user account to be linked to multiple ILS accounts, for scenarios where (for example) a single VuFind® instance is connected to multiple libraries, and users might have accounts in multiple locations. The Demo driver (which simulates an ILS using entirely fake data) can be used for testing library cards. Follow these steps:
VuFind® includes a feature to merge locally-stored data like tags and comments when a service reports that a record's unique identifier has changed. This can occur in some third-party APIs and can also be useful when migrating to a new ILS (since you can index your old IDs in a “previous ID” field and turn on the associated fallback record loader to trigger automatic deduplication).
When a changed ID is found, an automatic process of reconciling and deduplicating saved data occurs. These steps, combined with data in the default test data, can allow you to confirm that this process works correctly.
Here are step-by-step instructions (examples assume you are running your test environment at http://localhost/vufind_test – substitute your own base path as needed):
http://localhost/vufind_test/Record/vtls000000329
in a standard test environment, create an account, and save the record to your favorites. You can also add comments, record-level tags or other data if you wish to make the test case more complex.update resource set record_id='(IeDuNL)1048' where record_id='vtls000000329';
– this will change the record you just created so that its ID matches the simulated “old ID” value we will be using for the record instead of the id value, which will let us simulate a record ID change.http://localhost/vufind_test/Record/vtls000000329
in your browser, and repeat saving the record and adding other user data that you wish to test merging.http://localhost/vufind_test/Record/(IeDuNL)1048
– you should see exactly the same record that you saw in the other link, and this should trigger a data merge in the database.VuFind® allows users to view (and in some cases purge) their transaction history, but this functionality is disabled by default. To see how it behaves, follow these steps: