opened
SimonFinney
username_0
## Summary

Discussion around how testing could work across Cloud Pak components packages, and what best practices are available to be leveraged from Carbon and other teams - For example:

- Accessibility
- End-to-end
- Unit
Testing
issue
created
matthew-chirgwin
username_1
I personally I am fan of behavioural testing. It focuses the developer’s mind on the end user of whatever they are producing, and in turn means what a user actually does is tested, rather than the individual internals pieces which make up the whole. It is a very different way of approaching testing - which at first can seem cumbersome and is typically takes longer to complete compared to more traditional methods. The benefits however outweigh the cons for me - you test what the user does, and that in turn returns the best confidence that feature X meets its requirements.

I recently worked on an open source UI for the product I work on (https://github.com/ibm-messaging/kafka-java-vertx-starter). For that UI we were followed this behavioural first approach for the vast majority of the UI. As a stack we used:

- Jest
- React-testing-library (vs Enzyme - enforced testing as a user/no internals access)
- Cucumber (via gherkin-jest - to integration test components together)
- Playwright (augmented with jest-playwright-preset/gherkin-jest - to drive the whole UI in an end to end manner)

We were very opinionated about the type of components we were writing, and how they should be constructed and composed. One of the first requirements of any new component was a Readme, calling out intent, usage and user (which we then used as doc in storybook). Often the end user of these components would not be someone using the UI, but the developer using the component to construct the UI. These considerations were then used to define test cases and scenarios. Typically, the more presentational components were, the more ‘unit’ tested they became. For components which were more complex, the behavioural approach abstracted away particulars such as triggering data fetching or getting the component in the right state - we physically drove the component to show it achieved a purpose, and in turn, covered all the pieces which allowed it to do so.

Not everything is a component however. For helpers and custom hooks, we typically wrote more unit style tests, as this was appropriate for those particular pieces of function.

In the end, we ended up with a test suite which covered the whole UI in context - which gave us the confidence that it met the stated goals, and if we were to develop it further, we would know if something were to break. We also (as we integrated Jest) got things like code coverage for free, as an extra metric to confirm we had all bases covered. This approach really worked for us, and I would recommend it here for discussion.

We didn’t do it for this UI, but for another we used the end to end tests as a chance to capture and automate a11y testing. As a user navigated through the test, we would scrape the page, and then run that through the aat tooling to capture violations. This worked well, but did have flaws - mainly timing issues causing inconsistent results.
comment
created
SimonFinney
username_0
Splitting this out further into #20 , #21 , and #22 for us to align on independently
comment
closed
SimonFinney
username_0
issue
created
SimonFinney
username_0
Closing in favour of the above issues for deeper discussion
comment