About Features Downloads Getting Started Documentation Events Support GitHub

Love VuFind®? Consider becoming a financial supporter. Your support helps build a better VuFind®!

Site Tools


Warning: This page has not been updated in over over a year and may be outdated or deprecated.
development:testing:manual_testing

Manual Testing

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.

General Considerations

Browser Testing

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:

  • Firefox
  • Edge
  • Chrome
  • Safari
  • Opera

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.

Input Testing

Some general patterns to follow when testing new features:

  • Test fields stored in the database for SQL injection vulnerabilities.
  • Test fields sent as Solr searches for vulnerability to syntax errors.
  • Test fields where input is stored and displayed back for XSS vulnerabilities and missing HTML/URL encoding. A good test is “<script>alert('test');</script>” – if there is an XSS vulnerability, this will cause a pop-up to appear!

If you find something that breaks, please don't just fix it – also build an automated test to prevent regressions!

Testing Integrations

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:

  • Export Targets (e.g. EndNote, RefWorks, etc.)
  • ILS Drivers (e.g. Alma, Aleph, etc.)
  • Search Backends (e.g. EDS, Summon, WorldCat, etc.)
  • SMTP integration (e.g. sending emails via various services)
  • SMS integration (e.g. sending texts via various services)

If you test and discover that something is not working, please open a JIRA Ticket to report the problem.

Feature Testing

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.

Hierarchical Facets

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:

  1. In facets.ini, at the top of the [Results] section, add hierarchical_facet_str_mv = Hierarchy
  2. Also in facets.ini, in the [SpecialFacets] section, add hierarchical[] = hierarchical_facet_str_mv
  3. Now, in the user interface, you should see the facet tree displayed at the top of the sidebar facets in search results
  4. To test “exclude facets” you can add 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.
  5. To test “OR facets” you can add 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.
  6. To test a hierarchical facet on the home screen, add 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.

Library Cards

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:

  1. In config.ini, in the [Catalog] section, set driver to “Demo” and library_cards to “true”.
  2. In the VuFind® web interface, create a user account (or log in to an existing account).
  3. On the “Your Account” page, click on “Library Cards” in the side menu.
  4. You can now create multiple named library cards with different login credentials; by default, the Demo driver accepts all credentials, so you can make up whatever usernames and passwords you like.
  5. Now if you go to the “Profile” page, you should see a drop-down menu of library cards at the top of the “Library Catalog Profile” section of the page. When you switch the values in the drop-down menu, you should see the accounts associated with the different cards. The “First Name” field will include the username that you provided as evidence that the data is actually being switched.
  6. All other features related to the ILS (holds, fines, etc., etc.) should also display the library card selection control.

Merging Record Data When IDs Change

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):

  1. Go to 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.
  2. Log in to your database on the server and run 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.
  3. Now refresh 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.
  4. In searches.ini, uncomment the fallback_id_field setting and set it to ctrlnum. This will put the system into a mode where, if it tries to do a lookup by ID and can't find a match in the regular ID field, it will fall back and check the ctrlnum field… and if it finds a match, it will then merge any existing data associated with the ctrlnum value into the associated id value.
  5. Now go to 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.
  6. Now you can check that everything merged together correctly – all of the tags, favorites, comments and notes you created in steps 1 and 3 should be combined together in the record view.

Transaction History

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:

  1. In config.ini, in the [Catalog] section, set driver to “Demo”.
  2. In Demo.ini, in the [TransactionHistory] section, set enabled to true.
  3. After creating an account and logging in, a new option should now be available in the account side menu to allow access to transaction history. The Demo driver will populate this with simulated data (and you can log out and back in again to generate a new set of simulated data).
development/testing/manual_testing.txt · Last modified: 2023/09/07 13:29 by demiankatz