Ensuring stability of the Open Targets Platform: the case for automated end-to-end testing

The Open Targets Platform integrates vast amounts of biological and clinical data to help researchers identify and prioritise drug targets. With every release cycle, millions of data points are processed, integrated and made available to researchers across the world. As well as handling huge data volumes, in 2025 alone, we introduced the variant, credible sets and study pages each containing several widgets and features.

This continuous growth is a testament to the work done across the Open Targets collaboration and our Platform team. However, it also introduces an inevitable challenge: as a platform grows in complexity, maintaining stability becomes increasingly difficult.

Data flows through multiple pipelines, services, and interfaces before being presented to the user. While each individual component may work correctly in isolation, issues can emerge when these components interact. Even small changes in one part of the system may unexpectedly affect another.

To address this challenge, the Open Targets Frontend Team has introduced automated end-to-end (E2E) testing for the Platform’s user interface and also a scalable way to write them. These tests help ensure that core user journeys and data presentation patterns continue to function correctly as the Platform evolves.

Why end-to-end testing?

Software testing is often visualised as a pyramid.

• Unit tests validate individual pieces of logic.
• Integration tests ensure services interact correctly.

End-to-end tests simulate how a real user interacts with the system.

Each layer serves a different purpose.

The closer we test to individual components, the faster and cheaper tests are to run. However, these tests cannot always detect issues that arise when multiple parts of the system interact.

End-to-end testing sits at the top of the pyramid and focuses on validating complete user workflows.

For example, an e-commerce website would prioritise testing workflows such as:

• Adding items to a cart
• Completing payment
• Creating an order

If any of these fail, the platform fails from the user's perspective; even if all internal services technically function. The same idea applies to the Open Targets Platform. While the Platform is not transactional like an online store, it still has critical user interactions that must remain reliable.

Examples include:

• Navigating between entity pages (targets, diseases, drugs, variants)
• Viewing summary widgets and tables
• Interacting with filters and data visualisations
• Accessing integrated datasets across pages

End-to-end tests allow us to repeatedly validate these interactions automatically, providing confidence that the Platform behaves correctly across releases.

A practical challenge: testing a data integration platform

The Open Targets Platform presents a unique testing challenge. Unlike traditional applications where workflows involve specific actions (such as completing a purchase), our platform focuses on data exploration and presentation.

A naive approach would be to test every individual data point through the UI. However, this approach quickly becomes impractical:

• The Platform contains millions of data points
• Data is updated regularly
• Test maintenance would become overwhelming

Instead of testing individual data values, we focus on testing patterns of data presentation.

In other words, rather than verifying every piece of data displayed on a page, we validate that:

• Data tables render correctly
• Filters behave as expected
• Summary widgets load and display structured information
• Navigation between entities functions correctly

By focusing on these patterns, we achieve scalable and maintainable UI testing.

Our approach: Page Object Model

To implement this testing framework, we adopted the Page Object Model (POM) design pattern.

The concept was originally described by Martin Fowler (initially referred to as the Window Driver Model) and later formalised by Sam Woods at Microsoft.

The central idea is simple:

“Instead of writing tests that directly interact with page elements, we create abstractions that represent pages or components.”

These abstractions expose simple methods for interacting with the UI.

For example, instead of writing test code that repeatedly queries HTML selectors, we create objects such as:

• TargetPage
• DiseasePage
• DrugPage
• SummaryWidget
• EvidenceTable

Each object contains methods describing meaningful interactions, such as:

• Navigating to a specific entity page
• Extracting summary information
• Accessing table columns
• Interacting with filters

This approach provides several benefits:

• Tests become easier to read
• UI interactions are encapsulated in reusable components
• Changes to the UI require updates in only one place

In practice, this means our testing framework behaves almost like a small software development kit  for interacting with the Platform UI.

Beyond testing: interactors as utilities

One interesting side effect of the Page Object Model approach is that these objects can serve purposes beyond testing.

Because the framework encapsulates interactions with Platform pages and widgets, it can also be used as a programmatic interface for exploring the UI.

For example, developers or analysts could:

• Navigate across entity pages
• Extract structured data from tables
• Inspect widgets programmatically
• Validate presentation patterns for specific datasets

In this sense, the framework becomes a reusable tool for interacting with the Platform—not just a testing mechanism.

Configurable testing scenarios

While the tests themselves are designed to validate generic presentation patterns, we still need the flexibility to run them across different scenarios.

For example:

• Running tests against different entity pages
• Testing multiple datasets
• Targeting specific example cases

To support this, we introduced configurable test scenarios.Test behaviour is defined through configuration rather than hardcoded values. This allows us to:

• Change which pages are tested
• Introduce new cases without modifying test logic
• Maintain a scalable and flexible testing suite

This configuration-driven approach allows the same tests to be reused across different contexts.

Integration with our development workflow

Automated tests are most valuable when they are tightly integrated with the development workflow. Our testing framework is integrated into GitHub through automated workflows.

Pull request testing

When a pull request is opened, a smoke test suite runs automatically. This provides quick validation that critical UI interactions remain functional. Before merge, the test results are verified by a member of the Frontend Team and decides whether to merge the pull request.

Full test suite

Our developers and product manager can also manually trigger the full test suite when deeper validation is required.

The resulting reports are downloadable as GitHub artifacts and provide:

• A summary of passed and failed tests
• Detailed logs
• Playwright traces and recordings, which allow us to replay the exact sequence of events that led to a failure

This significantly simplifies debugging when issues arise.

Documentation and developer experience

Because the testing framework exposes reusable objects and interactions, documentation is essential.

We treat the framework similarly to a small library.

Documentation is generated directly from code comments using TypeDoc, ensuring that the API documentation stays synchronised with the implementation.

Whenever the interactor APIs change, documentation can be regenerated with:

```yarn docs:test_interactors```

This ensures that developers always have up-to-date information about:

• Available page objects
• Supported interactions
• Expected parameters

Where we go from here

The introduction of automated end-to-end testing provides a strong foundation for future development of the Platform.

With a stable UI testing framework in place, several exciting directions become possible.

Test-driven development

One natural question is whether we should adopt Test-Driven Development (TDD) practices for UI features. In this model, tests are written before the feature is implemented, ensuring that behaviour is defined and validated from the outset of feature design and development.

While not all UI features require strict TDD, the presence of a robust test framework makes this approach much more feasible.

Programmatic test scaffolding

Another interesting direction involves automatically generating test scaffolding.

Using Abstract Syntax Trees (ASTs) combined with large language models, it may be possible to generate test templates for new components or pages automatically.

This could significantly reduce the effort required to maintain comprehensive test coverage as the Platform evolves.

Conclusion

As the Open Targets Platform continues to grow, maintaining reliability becomes increasingly important.

Automated end-to-end testing allows us to:

• Validate critical user interactions
• Detect regressions early
• Provide confidence in Platform releases
• Reduce manual verification effort

By adopting a scalable testing architecture based on the Page Object Model, configurable scenarios, and integrated CI workflows, we are building a foundation that supports both stability and future innovation.

Ultimately, these efforts ensure that researchers using the Platform can continue to rely on it as a robust and trustworthy tool for exploring biomedical data.