I understand this change was motivated by a ftr test that was failing.

Nonetheless, I think this is not the right file. The test failing tests this page http://localhost:5620/app/uptime/certificates. That certificate table lives in x-pack/solutions/observability/plugins/uptime/public/legacy_uptime/components/certificates/certificates_list.tsx instead (AFAIK)

🤦🏻 That explains why I couldn't get the data-test-subj to appear in DOM and why I decided to go with a class name in the first place. I 100% prefer to query a test subject instead 👍🏻

I like the idea of referencing the table directly to get the visible text. But we're trying not to rely on css selectors in our functional tests and rather use data-test-subj.

You could add a data-test-subj to the EuiBasicTable in x-pack/solutions/observability/plugins/uptime/public/legacy_uptime/components/certificates/certificates_list.tsx and then use it here like this:

    <EuiBasicTable
      data-test-subj='uptimeCertificatesTable'
      loading={certificates.loading}
      columns={columns}
      items={certificates?.certs ?? []}
      pagination={pagination}
      onChange={onTableChange}
      sorting={{
        sort: {
          field: sort.field,
          direction: sort.direction,
        },
      }}
      noItemsMessage={certificates.loading ? LOADING_CERTIFICATES : NO_CERTS_AVAILABLE}
    />

    async displaysEmptyMessage() {
      await testSubjects.existOrFail('uptimeCertificatesTable');      
      expect(await testSubjects.getVisibleText('uptimeCertificatesTable')).to.include.string('No Certificates found.');      
    }

lmkwt!

For context: the ftr test was failing because the new version of EUI introduces some accessibility enhancements that make the noItemsMessage be rendered twice: one for screen readers and another for the actual UI. I suspect this caused the test to look for visible text in the component that is rendered for screen readers only, and that made it fail.

@miguelmartin-elastic I second the idea of not relying on CSS selectors and using data-test-subjs instead. Even if the class is "stable", they are not dedicated to querying elements, that's what the data attribute is for. Hopefully with the Scout tests this will change.

I updated the test and the usage you mentioned on 65abe09

One note though: we should try not to pass anything other to noItemsMessage than a string or <FormattedMessage />. Technically speaking, span is not far off but it can lead to unexpected behaviors in the tests (like here because of duplication).

Let's see if the CI passes and ofc let me know if this change is okay for you 🙏🏻 Thank you for all the support, Miguel! It's highly appreciated.

cc @tkajtoch

Totally agree. Thanks both for applying the changes !