lecture 15 of 170 completed

Shipping your framework as a package

When three teams need the same helpers, the code becomes a product with users. Versioning and migration become your problem.

What you'll learn

  • When shared test code should become a package
  • What versioning and deprecation you then owe your users
  • Why a custom matcher is the highest-value thing to ship

Three teams need the same fixtures, the same API client and the same page objects. Each writes their own. Six months later there are three logins that behave differently and a bug fixed in one of them.

The answer is to publish the shared layer as a package. That converts your test code into a product with users, and the obligations that come with that are what this lecture is about.

What belongs in the package.

Framework-level things: the extended test object, authentication fixtures, API client base classes, data factories, shared page objects for screens every team touches, custom matchers, and reporting helpers.

members only

Keep reading with the full course

The Foundations track and the first 5 lectures of each framework are free. This lecture is part of the paid course, which unlocks every lecture, all three frameworks, and downloads.

See the options →