To ensure that this project credibly fulfils its stated and intended aims, evidence is required. There are two complementary aspects to that: system and integration tests (both ones that pass and those that fail, indicating gaps discovered by the research work undertaken), and demonstrations.

Discussion ticket for this page

Testing

This involves each system in the federation having tests that indicate whether it can share data with the other two as intended. These tests will mainly involve data pushes - which imposes primary responsibility on the sending system for successful delivery of correct data - but will also include some data pulls, since that has emerged as part of valid workflows in a federated context. The only corresponding responsibility of the systems receiving requests is to provide HTTP endpoints (and associated credentials) that sending systems can use.

Proposed tests

1. Transmission of data updates: when an update occurs in the tested system, the update is automatically transferred (on a schedule, or via an event) using an HTTP POST request to each federated system conforming to the target systems' specification, taking into account considerations such as:
   1. Data formats;
   2. Entity Identities (timesheets, etc.);
   3. User Identities;
   4. Access Control (showing the difference in approach between PreJournal and the other two systems in the federation);
   5. Data Integrity (both unaltered and unduplicated);
   6. Etc.
2. Data requests: when one system solicits timesheet data from a federated system via its API using an HTTP GET request, these data are provided correctly in the serving system's format.
3. Transmission of data updates: if the data sent to the federated system are incorrectly formatted, the transfer attempt fails.
4. Data sovereignty (where applicable): data received by the tested system from other federated systems are read-only in the tested system (currently applies only to PreJournal).
5. Data integrity: individual entities transmitted by systems able to sign data are expected to remain accurate as they travel between systems. Data integrity violations may also arise from wrongly ordered updates; however, that is out of scope for the project.
6. Data deletion: to be discussed

Demonstrations

These can be live, and should also be recorded for those that are unable to attend the live occasion.

Demo scripts

The following are proposed:

1. Show all 3 federated systems with no timesheet data for a particular day / project; enter timesheet data into one of those systems; following transfer from that system to both other federated systems, show that those data now appear accurately and once only in the other two systems.
2. For that same day / project, enter further timesheet data into one system; following transfer from that system to both other federated systems, show that those data now appear in those other systems.
3. For that same day / project, amend timesheet data in one federating system; following transfer from that system to both other federated systems, show that those data now appear correctly in those other systems.
4. Access control:
   1. Attempts to amend timesheet data in PreJournal that originate in timeld using Tiki's credentials for PreJournal fail.
   2. Attempts to amend timesheet data in PreJournal that originate in Tiki using timeld's credentials for PreJournal fail.
   3. Attempts to amend timesheet data in timeld that originate in Tiki using PreJournal's credentials for timeld succeed.
   4. Attempts to amend timesheet data in timeld that originate in PreJournal using Tiki's credentials for timeld succeed.
   5. Attempts to amend timesheet data in Tiki that originate in PreJournal using timeld's credentials for Tiki succeed.
   6. Attempts to amend timesheet data in Tiki that originate in timeld using PreJournal's credentials for Tiki succeed.