Skip to content

Conversation

@antonbsa
Copy link
Member

What does this PR do?

Adds test for the following samples:

  • sample-audio-settings-dropdown-plugin
  • sample-camera-settings-dropdown-plugin
  • sample-custom-subscription-hook
  • sample-data-channel-plugin

More:

Fixes Typescript errors and enhances types

Copy link
Collaborator

@GuiLeme GuiLeme left a comment

Choose a reason for hiding this comment

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

Besides those comments I left, one thing I notice was that some tests were failing here because it wasn't supporting interaction with multiple plugins (For example: the actions-button-dropdown - It hasn't got the expected structure, because there were multiple extensible areas from plugins there)

One suggestion I would make is (This could be done in another PR, just let me know):

  • In the beforeAll function, you could insert another callback that verifies if there are other plugins within the test meeting (just need to check the log for loaded plugins) - If it's not possible to add more callbacks to the beforeAll function, you can create a beforeAllWrapper that will run the checkPluginAvailability and the new verifyOnlyPluginInMeeting functions in it - That way, the tester will know fast enough what to do (just remove the current installed plugin from bbb-web.properties).

expect(urlsJson?.text, 'should log the correct TEXT URL for the second slide').toBeDefined();
expect(urlsJson?.text, 'TEXT URL should be a valid URL').toMatch(/^https?:\/\/.+/);

await sampleTest.modPage.page.locator(e.skipSlide).selectOption({ label: 'Slide 15' }); // last slide
Copy link
Collaborator

Choose a reason for hiding this comment

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

This line hardcodes the slide number assuming that the default PDF coming to the whiteboard is the same as the one that comes by default when installing BBB. In my case, that was not true, in fact, I had a 4 slides PDF.

I suggest to change this to the number of pages from default.pdf accessible via https://<bbb-base-domain>/default.pdf (Then you are going to have to use the pdfjs-dist or pdf-lib to get it), or if you have access to the graphql via browser console, you can get it via subscription.

Copy link
Member Author

Choose a reason for hiding this comment

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

BBB automated tests start from the premise that "the testing environment is set with default settings". So it's expected to have the default.pdf loaded in the session where the test is running. Using any lib to check a file or something like that will add unnecessary complexity that we do not aim for in tests: they must be reliable and strictly context-scoped.

to fit the changes you suggested, I propose:

  • instead of going to "slide 15", go to the second slide
  • in case the "next slide" button is disabled, we assume the current presentation has a single page (a presentation with more pages is required to validate the plugin's feature) and fail or skip the test with a descriptive log.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Hm, I see. So the idea of going for the 15th slide to test if the button doesn't appear is pretty good and covers all scenarios - I wouldn't mind letting it there, knowing the premise you mentioned. However, it would be interesting for the tester, or developer that is testing the code, to know why the fail happened, so for that I would suggest, if possible:

  • Check if the 15th slide is there, if so, proceed with the test, if not, then log an error saying that the presentation is likely not the one that comes in default installations of BBB (And ask the dev to use it so the test runs properly);

If that's not a valid idea, we can:

  • Change the error log (when the test fails in that specific selector) to warn the developer that the presentation they have is likely not that of the default installation - That could possibly be done with a try/catch (?);

Copy link
Member Author

Choose a reason for hiding this comment

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

now I got what you are saying. 86b947e addresses your suggestions. it dynamically gets the last slide (also checking before if the presentation has more than 1 slide - required for testing the sample plugin)

@antonbsa
Copy link
Member Author

antonbsa commented Jun 23, 2025

some tests were failing here because it wasn't supporting interaction with multiple plugins

the actual issue was 2 plugins injecting separator elements, which previously had the same data-test attribute - failing tests that expected a single separator match. a65a949 makes this attribute to be set dynamically.

Note: It makes a lot of sense for these types of failures to be addressed, as we expect all plugin tests to run properly, regardless of how many others are configured in the session.

Copy link
Collaborator

@GuiLeme GuiLeme left a comment

Choose a reason for hiding this comment

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

Changes look solid to me! Let's wait for the merge and then bump SDK's version and tag (so we update the CORE)

@antobinary antobinary merged commit 3ac1225 into bigbluebutton:v0.0.x Jun 23, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants