Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FDC3 Compliance Check - First Iteration #615

Closed
wants to merge 25 commits into from

Conversation

dbutt-scottlogic
Copy link

A simple first iteration of compliance tests that verifies the existence of desktop API methods.

  • Checks for FDC3/FDC3Ready event. Displays error if not found in 5 seconds.
  • Launches a mocha test suite that runs automatically
  • For each API method, calls the method. If no unexpected error, test succeeds.
  • See README for instructions

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Mar 7, 2022

CLA Signed

The committers are authorized under a signed CLA.

@kriswest kriswest requested a review from a team March 16, 2022 13:12
@kriswest kriswest added api FDC3 API Working Group project infrastructure toolbox Apps or code that isn't part of the standard but supports it use labels Mar 16, 2022
Copy link
Contributor

@kriswest kriswest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems a reasonable start on the conformance project. At present, the tests only check if functions are callable and not any of their behavior (which presumably we'll see some of in a future update). I've made some comments about checking responses in these initial checks however as I think you could do some confirmation that the app(s) are set-up correctly for the rest of the tests.

A correction is needed in the fdc3.joinChannel test as indicated.

Readme could be expanded to cover more of the set-up for the test - including customisation to the manifest that will be required. Could also eventually include 1.2 manifests for the major containers (vendors to supply) - thankfully 2.0 will support multiple manifests and (if possible) some more vendor agnostic fields making them less necessary.

toolbox/fdc3-compliance/README.md Outdated Show resolved Hide resolved

## Application Definition

A basic FDC3 application definition, as defined in the [application directory specification](https://fdc3.finos.org/schemas/1.2/app-directory#tag/Application), is supplied in the file `appDefinition.json`. This may be useful when adding the conformance tests to an application directory.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The getting started section could be expanded upon:

  • add a link to the app definition file
  • in 1.2 the definition must be expanded on with a manifest for the container to start it
  • if the desktop agent doesn't connect to an appD / has other configuration steps they'll need to be taken

Then, once the application definition has been added:

  • Do you just launch it to start the test?
  • What should they then expect to happen?
  • etc.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can definitely bulk up the README in this area. For this version, the tests run automatically on load, so we will make that clear.
As far as configuration goes, we are avoiding putting anything vendor-specific in the documentation, but we will make it clear that there may be additional configuration required (the current file works as-is with the existing inline manifest with Glue42).

toolbox/fdc3-compliance/src/FDC3Conformance.ts Outdated Show resolved Hide resolved
toolbox/fdc3-compliance/src/appDefinition.json Outdated Show resolved Hide resolved
toolbox/fdc3-compliance/src/test/fdc3.findIntent.ts Outdated Show resolved Hide resolved
try {
await window.fdc3.findIntent("ViewChart");
} catch (ex) {
if (ex !== ResolveError.NoAppsFound) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about ResolveError.ResolverTimeout and ResolveError.ResolverUnavailable? They are both valid errors but probably mean the test can't continue - while NoAppsFound might be valid IF they don't have another app that handles that.

To actually test handling of intents with no apps that support them (i.e. that the correct error is returned), use some long gobbledegook intent name.

This is also a good place to check the setup (including your custom intent) was completed correctly (e.g. your custom intent was registered) and to provide good error messaging if not.

Also (unsupported) other errors - should fail out the test with a different message (as those are not a valid response).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed - those are all things on the TODO list for the next iteration. For this version, anything other than the expected responses will cause a test failure.

toolbox/fdc3-compliance/src/test/fdc3.joinChannel.ts Outdated Show resolved Hide resolved
dbutt-scottlogic and others added 2 commits March 22, 2022 14:31
Address PR feedback:
- Clean up resources, i.e. unsubscribe listeners and leave channels
- Use first system channel in joinChannel test
- Use non-existent intent names for consistency
- Remove unnecessary top-level async from tests
- README improvements
Copy link
Member

@ggeorgievx ggeorgievx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the revisit, @dbutt-scottlogic ! We are almost there.

Copy link
Contributor

@kriswest kriswest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First off, apologies for the delay (big product release and a vacation got in the way 😬 ). As penance I've tried to add full suggestions you can commit for proposed changes.

Overall it LGTM, however, I spotted one possible issue with error handling. Technically, the FDC3 spec says that Error objects should be thrown with the strings from the error enumerations, where the tests are assuming the strings themselves will be thrown (its annoying that javascript allows this IMHO, it perhaps should have upgraded strings to errors). E.g.

If the resolution fails, the promise will return an Error with a string from the ResolveError enumeration.
Finsemble appears to be throwing the strings, rather than Errors, which may have steered you wrong on this... The suggestions I've put in would handle it either way - however we should probably have a discussion on this (in the Standards Working Group) as it makes error handling more complex.

Also the test framework is not happy with strings being thrown on failures (Finsemble is throwing the wrong error string for fdc3.open), resulting in:
image


## Application Definition

A basic FDC3 application definition, as defined in the [application directory specification](https://fdc3.finos.org/schemas/1.2/app-directory#tag/Application), is supplied in the [file](./src/appDefinition.json) `appDefinition.json`. This may be useful when adding the conformance tests to an application directory. This file may need to be updated with additional manifest information, depending on the desktop agent. Consult the host environment documentation for information on configuring new applications.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor comment, but I'd move the appD file out of the src dir and into the root of the project (I missed the link and went looking for it)

@@ -0,0 +1,5 @@
describe("fdc3.getOrCreateChannel", () => {
it("Method is callable", async () => {
await window.fdc3.getOrCreateChannel("FDC3Conformance");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this case will be expanded in the next version to check a Channel object was actually returned.

@@ -0,0 +1,5 @@
describe("fdc3.getSystemChannels", () => {
it("Method is callable", async () => {
await window.fdc3.getSystemChannels();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again I expect this will be expanded in the next iteration to check that the expected response was received, particularly as the joinChannel test relies on it doing so

it("Method is callable", async () => {
try {
await window.fdc3.open("ThisAppDoesNotExist");
throw ExpectedErrorNotThrownError;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
throw ExpectedErrorNotThrownError;
throw new Error(ExpectedErrorNotThrownError);

await window.fdc3.findIntent("ThisIntentDoesNotExist");
throw ExpectedErrorNotThrownError;
} catch (ex) {
if (ex !== ResolveError.NoAppsFound) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comparison might not be correct if an Error object was thrown rather than just the string message, which is best practice in JS and is technically whats described in the API docs:

If the resolution fails, the promise will return an Error with a string from the ResolveError enumeration.

Suggested change
if (ex !== ResolveError.NoAppsFound) {
if ((ex.message ?? ex) !== ResolveError.NoAppsFound) {

Comment on lines 22 to 23
if (ex !== ResolveError.NoAppsFound) {
throw ex;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comparison might not be correct if an Error object was thrown rather than just the string message, which is best practice in JS and is technically whats described in the API docs:

If the resolution fails, the promise will return an Error with a string from the ResolveError enumeration.

Suggested change
if (ex !== ResolveError.NoAppsFound) {
throw ex;
if ((ex.message ?? ex) !== ResolveError.NoAppsFound) {
throw new Error(ExpectedErrorNotThrownError + "\nException thrown: " + (ex.message ?? ex));

Comment on lines 11 to 12
if (ex !== OpenError.AppNotFound) {
throw ex;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comparison might not be correct if an Error object was thrown rather than just the string message, which is best practice in JS and is technically whats described in the API docs:

...it returns an Error with a string from the OpenError enumeration.

The re-thrown exception should probably be a variant of ExpectedErrorNotThrownError

Suggested change
if (ex !== OpenError.AppNotFound) {
throw ex;
if ((ex.message ?? ex) !== OpenError.AppNotFound) {
throw new Error(ExpectedErrorNotThrownError + "\nException thrown: " + (ex.message ?? ex));

Comment on lines 22 to 23
if (ex !== ResolveError.NoAppsFound) {
throw ex;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (ex !== ResolveError.NoAppsFound) {
throw ex;
if ((ex.message ?? ex) !== ResolveError.NoAppsFound) {
throw new Error(ExpectedErrorNotThrownError + "\nException thrown: " + (ex.message ?? ex));


try {
await window.fdc3.raiseIntentForContext(context);
throw ExpectedErrorNotThrownError;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
throw ExpectedErrorNotThrownError;
throw new Error (ExpectedErrorNotThrownError);

Comment on lines 22 to 23
if (ex !== ResolveError.NoAppsFound) {
throw ex;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (ex !== ResolveError.NoAppsFound) {
throw ex;
if ((ex.message ?? ex) !== ResolveError.NoAppsFound) {
throw new Error(ExpectedErrorNotThrownError + "\nException thrown: " + (ex.message ?? ex));

"publisher": "FINOS",
"icons": [
{
"icon": "https://fdc3.finos.org/img/fdc3-logo-2019.png"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This logo doesn't work well as an icon, i'd suggest swapping out for http://fdc3.finos.org/toolbox/fdc3-workbench/fdc3-icon-256.png
(which you can copy into this project)

Move appDefinition.json to root of project and improve error handling
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Apr 29, 2022

CLA Signed

The committers listed above are authorized under a signed CLA.

@kriswest kriswest added the conformance Conformance testing framework label Apr 29, 2022
@ColinEberhardt
Copy link
Contributor

@kriswest I've added @AidanZealley to the CLA, can you please re-run the checks?

@kriswest
Copy link
Contributor

kriswest commented May 6, 2022

/easycla

1 similar comment
@kriswest
Copy link
Contributor

kriswest commented May 6, 2022

/easycla

@kriswest
Copy link
Contributor

kriswest commented May 6, 2022

@ColinEberhardt submitted a LF support request as I don't see the checks being re-run, pretty sure I'm doing that correctly

@kriswest
Copy link
Contributor

kriswest commented May 6, 2022

@ColinEberhardt support says:

I checked EasyCLA and there is no signature on file for https://github.com/AidanZealley ID: 2430106, Aidan needs to go to "Please click here to be authorized" link in the PR comment #615 (comment) and complete the signature and acknowledgment process for EasyCLA. Once done EasyCLA should authorize the commits c015038 and b1c63e6.

When you've got that done, comment /easycla to re-run the check.

@kriswest kriswest linked an issue May 13, 2022 that may be closed by this pull request
@AidanZealley
Copy link

/easycla

@kriswest
Copy link
Contributor

Closing as this project has moved to it own repo and will merge back a finalized build instead

@kriswest kriswest closed this Nov 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api FDC3 API Working Group conformance Conformance testing framework project infrastructure toolbox Apps or code that isn't part of the standard but supports it use
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FDC3 Software Conformance Framework
5 participants