Unit testing Flux?

The announcement for Flux included a brief section on the promise of testability.

It should be “testable.” Queries are code and they should be tested and checked into source control if they’re going to be a part of a long-lived application. Further, individual parts of queries should be testable in isolation. It should be possible for a user to build up a complicated query, but test each part of that separately.

I’ve interpreted this to mean some sort of unit testing framework or Flux-native testing features. Remarks from InfluxData folks seem to support this.

All my searches lead me to Golang unit tests for the source code of Flux itself (not what I’m asking about). And to be clear I’m not referring to a staging / pre-production / sandbox environment (which has its own value distinct from unit tests).

Does anyone know the state of unit testing Flux? Even if it’s not quite ready for prime time I’d like to play with it.

Any news or direction appreciated.

Hello @mkarlesky,
I believe this is what you want:
https://v2.docs.influxdata.com/v2.0/reference/flux/stdlib/testing/

Thank you for the quick response, @Anaisdg.

This does seem to be in the vein I’m asking about, yes. However, in their current form these functions appear most useful in making inquiries of data in production systems and taking action inside a Flux function. I can certainly see them applied in a full testing rig too.

What I’m after and what the Flux announcement seems to suggest is a means to thoroughly exercise production Flux outside of production use in some sort of testing harness (a.k.a. a unit test suite). This would require:

  1. An ability to run the same Flux function in production mode or in a separate test mode.
  2. Some sort of framework to exercise a Flux function from the outside (i.e. assertions on expectations outside of the production Flux code rather than inside the Flux function).
  3. An ability to easily input test case data into a given function apart from a production InfluxDB datastore or production SQL datastore.
  4. A means to compare the result of the function with an expectation and report the result.

I’m curious to see any roadmap for this or talk to anyone on the dev team working on this. I’d even be happy to be a guinea pig working with not-yet-ready testing tools. I know @pauldix has thoughts and has said something of the sort is coming.

My team is preparing to migrate our Kapacitor TICKScripts to Flux. Having a good means to test Flux code out of production would be incredibly useful.

Thank you again. Very eager to hear anything more.

Hello @mkarlesky,
This might also be useful to you:
Documentation for custom flux functions:
https://v2.docs.influxdata.com/v2.0/reference/flux/stdlib/contrib/
The contrib dir for custom flux functions:


The flux repo for compiling instructions:

A blog on creating a function and writing a test:

Another blog on creating a function and writing a test:

To compile flux:

go get github.com/influxdata/flux
go get github.com/influxdata/pkg-config
which -a pkg-config
> /Users/anaisdotis-georgiou/go/bin/pkg-config
> /usr/local/bin/pkg-config
export PKG_CONFIG=/Users/anaisdotis-georgiou/go/bin/pkg-config
cd flux
go generate ./libflux/go/libflux
go generate ./stdlib
go build ./cmd/flux

@Anaisdg Thank you again for your responses. I have been curious about how community contributed Flux would work. And, indeed, I see the unit testing happening in the custom Flux contribution.

However, this is not what I’m after. These examples demonstrate creating all new Flux capabilities in Go and unit testing the source Go. This is all very valuable, and I may well be creating new Flux abilities this way and contributing to the community.

My fundamental question remains about Flux’s ability to allow me to test my Flux code itself using Flux and doing so apart from production data. Generally speaking unit testing is written in the same language as the code under test (Flux in this case), and unit test suites execute outside of production systems. My read of the Flux announcement is that these abilities are planned to exist. I gather they do not yet exist. The articles you linked to actually demonstrate exactly what I’m asking about but in a Go context. I’m asking about a Flux context.

Perhaps I’ll submit an issue to the Flux project Github repository to inquire there.

Thanks for the great question. I wrote of a longer response here for future readers. https://github.com/influxdata/flux/issues/3054#issuecomment-666632891 The answers there rely on internal details of the current Flux implementation. Eventually we will expose this as a first class feature in native Flux, until have a look.

3 Likes

@mkarlesky,
Thank you for clarifying.
And thanks @nathaniel!

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.