We designed Artillery to be easy to extend and customize through a variety of extension APIs. Artillery comes with batteries included and many out-of-the-box integrations, but every non-trivial load testing project will require at least some customization at some point.
Artillery can be extended and customized in several different ways:
- You can customize the behavior of VUs with custom JS code (using any
npmmodule) for example to generate some data on-the-fly, or make a call to an external system.
- There's an API to record custom metrics to keep track of things that are specific to your system. For example a load test on a headless ecommerce API may track the number of products added to cart as a custom metric, or record the duration of several related transactions as one value.
- Both custom VU behavior and tracking custom metrics may be packaged as an Artillery plugin to make them easier to reuse across different tests. Plugins are also often used for sending Artillery test data to external systems.
- And finally, Artillery can be extended through its engine API to add support for a new protocol, or to provide an application-specific interface to make it easier to write tests. This guide will walk you through writing a custom engine for Artillery, using our new PostHog engine as an example.
When to create a custom engine?
There are two main use-cases for creating a new engine:
- Add support for a new protocol, e.g. extend Artillery with support gRPC
- Make an application or system easier to test with an engine that exposes higher-level app-specific actions
Adding support for a new protocol
You may already be familiar with the built-in HTTP engine, that provides support for
put, and other HTTP actions. The built-in Socket.IO provides
emit action to test Socket.IO systems, and the WebSocket engine provides WebSocket-specific
send actions. That's the first use-case for writing a new engine: adding support for a new protocol.
The other use-case is providing a higher-level abstraction while interacting with more complex systems. One example of this is our AWS Kinesis Engine which provides support for the
putRecord operation on Kinesis data streams. The underlying protocol used for Kinesis operations is HTTP, so you could load test a Kinesis stream using a series of HTTP POST requests with JSON payloads, it's much easier to do it through a Kinesis-specific interface that any user of Kinesis is already familiar with.
Let's create a PostHog engine
PostHog is an open-source product analytics platform (we are big fans of it here at Artillery). In the rest of this guide we will build a custom engine for interacting with PostHog via
posthog-node, while providing a simple method that can be replicated for other projects.
If you just want to test your PostHog instance, the final product of this article can be found at artilleryio/artillery-engine-posthog.
Let's get started!