feat: convenience method expectAllExist() for checking if multiple elements are detected (#APD-483)

[JohannesDienst-askui]

Adds the convenience method

    params: ExpectExistenceInputParameter[],
  ): Promise<ExpectExistenceReturnValue>

It takes an array of elements in the form of ExpectExistenceInputParameter:

export type ExpectExistenceInputParameter = {
type: ExpectExistenceAllowedElementClasses;
label: string;
matching?: 'similar' | 'exact' | 'regex';
relation?: {
  type: RelationsForConvenienceMethods;
  text?: string;
};
exists?: boolean;
};

and returns ExpectExistenceReturnValue with a property everythingExists and the the Input-Parameter with exists that shows if the element was found:

export type ExpectExistenceReturnValue = {
  everythingExists: boolean;
  elements: ExpectExistenceInputParameter[];
};

Comprehensive tests can be found in our QA-Repository: https://github.com/askui/askui-qa-system-test/pull/2

[adi-wan-askui]

First of all some likes:

• Test suites
• In code documentation very thorough

But I think the api and code is really complex for what it tries to achieve... Not sure if I am to review the api here, too, though. But I think we should have a quick call in order not to go back and forth because I think I may be lacking context.

[JohannesDienst-askui]

@adi-wan-askui Thanks for the help with improving the API and the Code ❤️ .

I refactored to use reduce() and to work for multiple elements.
Also the tests have been updated to reflect the new method signature.

I struggled to not use this.evaluateMatchingProperty(command, param.text) as FluentFiltersOrRelationsGetter as the method could return FluentFiltersOrRelations and there for exec() could return void. Any idea on how to get rid of it or is there no way to tell the type system it is safe in this case?

[adi-wan-askui]

Well done switching to reduce :)!

To your question: You can replace the typecasts by signature overloads. I provided an example to you inside a commit to this branch. You can replace the other typecast the same way.

Left some last ideas for improving the naming, usage of switch statements and documenting parameters.

[adi-wan-askui]

Well done :)