E2e Testing with Snowplow Mini/Micro

For engineers
1

Hi there,

I’ve recently been looking at our options for running some integration/end-to-end tests of our snowplow trackers.

Snowplow Micro looks great, and the two recent blog posts with examples were very informative. However, our application’s current CI/CD process does not lend itself well to being spun up and integration tested during the test/build pipeline (It’s mostly just unit tests being run during the build).

We do however have e2e tests running against the deployed infrastructure in our lower (aws) environments. I would like to add some e2e tests (i.e. using a browser automation framework) around the snowplow tracking to this test suite.

FWIW - We already have snowplow mini up and running, which would normally be used for manual verification/QA during the development phase.

If we were to use snowplow micro in this setup, I would need to host it inside the VPC somewhere (so it is visible to the deployed application/services). My question is, is this defeating the purpose of micro? If we already have a mini instance deployed, can we instead use that?

Is there a (public) API endpoint for elasticsearch on the mini instance that I could request (e.g. from a running test) events from? I haven’t been able to figure this out yet (I’m not too familiar with the mini setup). In the usage guide it looks like the elastic search api might be private only. Is this correct?

In summary,
I’m wondering what my best option for e2e testing against (already deployed) trackers is: should I try to get mini to do what I want, or instead host a micro instance (on ECS/Fargate), either ephemerally or permanently.

Any suggestions or feedback is welcome!

Regards,
Dylan

2

Hi Dylan, welcome to the forums!

Yes - you’d need to ensure your application can access Micro either via a private IP (in the same IP) or over the internet using a public IP - either method should work fine. If you use a public IP micro doesn’t need to be in the same VPC as your application itself - though generally micro is expected to run within a CI environment alongside the applicaiton.

You can definitely use a mini instance if you want. The API isn’t as agreeable as rather than the micro API you have to use the Elasticsearch API but that is certainly possible (and is in fact what we use for the ‘Stream Live Data’ feature in the Snowplow Inspector.

It is public but it looks like the documentation isn’t rendering that code block correctly which I’ve flagged as an issue. It uses basic auth (so you’ll need to provide a username and password) and then you should be able to access the full Elasticsearch API via

curl --user username:password -XGET http://public-ip-of-mini-instance/elasticsearch

You can also access all the query / metadata APIs here if you want to do something like filtering on a specific app_id or user_id.

3

Hi Mike,

Thanks for the quick response.
This was returned after executing that curl request:

<a href="/elasticsearch/">Moved Permanently</a>.

I was also looking at this blog post by yali, but it’s from 2016 - so it might be out of date.

4

Which version are you running of Mini? This has changed a little from earlier versions (which needed to be accessed over port 9200) to a /elasticsearch endpoint.

5

Hey Mike,

Just to update you. The http://<public-ip-of-mini-instance>/elasticsearch endpoint does appear to be working for me now. I must have been doing something wrong, which I now can’t reproduce.

Thanks for your help :slight_smile:

1 Like
6

Hello all, is Snowplow Micro able to fire events during the automated testing?

7

Do you mean Micro sending events to another destination?

Trackers typically send events to Micro - the service itself just collects and validates them during automated testing.

1 Like
8

No, let me try again. We are trying to figure out how to fire and test events before code changes are committed. Something like PageView, won’t trigger until someone is on a page and is viewing that page. So I’m asking, is there a way to manually trigger PageView from a command line prompt so that the event “triggers” and sends data or placeholder data over to Snowplow Micro and runs the schema validation.

Another way to ask is: What is the earliest point we can trigger an event for testing?

9

Hello @sandraqu !

What is the earliest point we can trigger an event for testing?

The earliest point is wherever your tracking code runs. More specifically, if, say, you are tracking the user journey on a page, as you mention above, then the ‘browser’ could for example be that earliest point.

Then, as you said:

Something like PageView, won’t trigger until someone is on a page and is viewing that page

This differs depending on whether you are interested in automated or manual testing, since, during automated testing you’d need a tool that will act as that ‘someone’ in an browser-like testing environment. There are such end-to-end web testing tools and frameworks, like Cypress and Nightwatch, and many more depending on the platform your digital products run.

Overall, what you need to do, either locally or in CI is:

  1. spin up Micro (as @mike said above, Micro will collect and validate the events fired next by the tracker).
  2. ‘point’ your tracker to Micro’s collector endpoint.
  3. interact or simulate an interaction with your page/mobile/server-side app.
  4. examine the end state(i.e. the events in Micro) to ensure that tracking continues to be properly configured and your code changes can be confidently committed.

Hope this helps!

You can find out more also in the docs here.

10

You can trigger events from the command line if you’d like (e.g., using a Curl GET request for example) but if you are looking to test before code has been committed then as @Ada has mentioned - the most common way to do so is by running front-end tests locally or in your CI/CD pipeline.