Skip to main content

12 posts tagged with "howto"

View All Tags

· 10 min read
Juan Gil
Hassy Veldstra

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 npm module) 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:

  1. Add support for a new protocol, e.g. extend Artillery with support gRPC
  2. 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 get, post, 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 connect and send actions. That's the first use-case for writing a new engine: adding support for a new protocol.

Application-specific engine

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.

PostHog banner

Let's get started!

· 8 min read

GraphQL is everywhere

GraphQL is becoming one of the standards among the different types of APIs available, thanks to their flexibility in allowing consumers to choose the data they need. Artillery can help you regularly test your GraphQL APIs to detect and eliminate potential problems, as shown in the article Using Artillery to Load Test GraphQL APIs. However, as seen in the article's examples, GraphQL's flexibility also makes it easy to have a less-performant API.

· 6 min read
Hassy Veldstra
Artillery Probe

Introducing Artillery Probe

Say hello to artillery probe, a Swiss army knife for testing HTTP. A smart and user-friendly HTTP client for the terminal which shows request performance waterfalls, and lets you set up expectations/checks on responses for quick-n-easy automated testing.

Think of it as curl with better UX for common use-cases, and a couple of extra powers.