Integration tests with Atlaskits

We’re trying to be good and get some real tests around some atlaskit components (especially the select component). While we’re able to get things like the button and checkbox components to work with click() etc - Select (and the other more advanced components) are not working.

Looking at the Atlaskit test code for Select: https://bitbucket.org/atlassian/atlaskit-mk-2/src/master/packages/core/select/src/components/tests/integration/select.ts we see that there is a @atlaskit/webdriver-runner package that does some magic. Can we find out what that magic is?

Does anyone else have any sample code that they could share of Select working in an integration test using webdriver?

Thanks,

/Daniel

1 Like

Hey @danielwester, I’ll try to find someone from the Design System team to respond.

This problem has applied to all Atlaskit components for 10 months None of these components can be built or tested by anybody outside Atlassian.

It was an intentional decision by the team, even with raging complaints from the community, and knowledge that it would cost many of us deeply. This ain’t your old Atlassian.

Hey Daniel,Thanks for raising this issue!

Would you be able to share the specific details you’re running into when trying to build integration tests against @atlaskit/select? Also can you share which test framework are you’re using to write these integration tests?

Cheers, Dan

Using WebdriverIO.io. I’m basically trying to just interact with it. We’ve ended up having to use the accessibility features to send key strings to it. This is after we had to interact with the underlaying dom elements in the checkbox module.

Is there some ways that I can have something like webdriver/puppeteer etc interact with Atlaskit without having to use an approach that will break when you change the internals? Don’t know if there’s some package somewhere that makes things a bit more “safer”?

oh I see! We actually recently added testid support to help avoid this issue. It basically works by passing some meaningful string to the testid prop, which we then attach to important dom elements in the component and children components. We’ll also append descriptive names to the dom elements, so your queries are more semantic. The result looks something like this testid=“my-string—element-descriptor So for example: testId=“testmodal--dismissButton. Best way to find what to query is by passing a testid and looking at the resulting dom output.

We list testId support in our props tables, so that’s the best place to start if you’re wondering ifa component supports it, in this case
https://atlassian.design/components/checkbox/code but you might need to upgrade if you’re on an older version. @atlaskit/select is a bit of a special case, so i’ll have to double check if it’s supported, since the underlying logic mostly passed through to react-select.

Let me know if that solves your problem :slight_smile:

@DanielDelCore @danielwester @dmorrow How are users not internal to Atlassian able to consume the repos like @atlaskit/webdriver-runner ?

This and other build tooling in Atlaskit was made private in early Jan 2020, preventing any Atlaskit repos from being built and tested outside of Atlassian since that time. All of these repos had been available for many years on npmjs.org for years.

If these repos have been made publicly available somehow, a lot of the community would be enormously grateful. Thanks.

Yeah but the challenge though becomes that I need to start understanding your dom structure and how you’re doing things - every components is slightly different. There doesn’t seem to be any type of pattern either which makes it so much harder for us (ie we have to start from scratch whenever we start using an interactive component).

I was hoping that you had some internal library that abstracted things out for us… At least with AUI there was the option of going directly to the standard input fields and read them… That doesn’t seem to be the case here… :cry: