[Feature Request]: `TealAppDriver` gain a `get_tab_choices()` function

[nikolas-burkoff]

Feature description

TealAppDriver has a method navigate_teal_tab() it would be nice to have get_tab_choices() function as well - then I could have a generic test which is "load app and navigate through all the tabs to make sure there are no validation errors".

Also, could TealAppDriver be exported? It's great functionality - I can use ::: of course in the meantime.

Would something like this work for me for now:

get_tab_choices <- function(app_driver) {
  html <- app_driver$get_html(".teal-modules-tree a")
  paste(html, collapse = "") |>
    rvest::read_html() |>
    rvest::html_elements("a") |>
    rvest::html_text() |>
    trimws()
}

I'm not sure the best value to put in get_html to make sure I capture all modules and nothing else.

Thanks

Code of Conduct

• I agree to follow this project's Code of Conduct.

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines.

Security Policy

• I agree to follow this project's Security Policy.

[donyunardi]

Hi @nikolas-burkoff, good to hear from you!

Also, could TealAppDriver be exported?

This is mostly used for unit tests, and I am not sure if I want to deal with the maintenance if we export it. ::: would work or getFromNamespace like how we did it in tmg:
https://github.com/insightsengineering/teal.modules.general/blob/fa652ba82994bc596ed17ffbaddd86c290527c16/tests/testthat/helper-TealAppDriver.R#L6-L25

it would be nice to have get_tab_choices()

This could be a nice addition.
@insightsengineering/nest-core-dev any opinion on this?

[llrs-roche]

I agree we shouldn't export testing features as this would make it harder to change the modules and tests.

Regarding get_tab_choices(), we kind of have this on #1653 with extract_wrapper_id (not sure if the ids of modules need to end with -wrapper but they matched the tabs for modules). But I think the idea @gogonzo had was to reduce the number of methods available on the TealAppDriver and make them more general. So I'm not sure how this will end up.

[gogonzo]

Hi @nikolas-burkoff isn't list of tabs deterministic? I mean that labels are the same as modules labels.

[nikolas-burkoff]

Hi @nikolas-burkoff isn't list of tabs deterministic? I mean that labels are the same as modules labels.

They are yes, but if I want to have a test that I can use whilst apps are being developed (say a sanity check for is the app clearly broken?) I would need to keep updating that test/keep track of the label names of the modules. It would be easier to just have a generic unchanging test which loads each module in turn to see if there's errors.

No need to actually add this in to the codebase of course but confirming whether get_tab_choices as defined above is the right function to use.

[nikolas-burkoff]

As for exporting the testing features, no problem - I don't mind pulling them out of teal.

You could imagine a longer-term aim of creating tealtest package to test teal apps just like shinytest2 tests shinyapps (and tealtest would be a suggests for teal) but I get that that wouldn't be a high priority

[gogonzo]

whether get_tab_choices as defined above is the right function to use.

Yes, nothing else than modules can be in this dropdown. It is safe to use this selector for many years ahead (#1675)

but I get that that wouldn't be a high priority

Wouldn't be ;]