nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Christianson <>
Subject Re: MINIFI-350 minifi-cpp end-to-end integration testing framework
Date Thu, 13 Jul 2017 14:34:41 GMT
Yes, I envision having a directory of declarative test cases. Each would include a flow yaml,
one or more input files, and expected outputs.

I’d like to document the convention before writing the implementation because if the conventions
are solid, we can change out the actual test driver implementation later on if needed.

Would it be best to document this in a section within /, or should I add a new file
such as /docs/, or /

As for where the test cases would be added, I was thinking maybe /docker/test/integration,
keeping consistent with the existing convention (i.e. /libminifi/test/integration).


On 7/13/17, 10:14 AM, "Marc" <> wrote:

    Hi Andy,
       I think this is a great idea to test integrating MiNiFi among multiple
    system components. Do you have a feel for how you will allow others to
    create test cases? Will you attempt to minimize the footprint of
    contributed tests by creating a bats based framework? I ask because it
    would be cool if contributors could supply a flow ( input ) and expected
    output and we automatically run the necessary containers/components. Is
    this along the lines of your vision?
    On Wed, Jul 12, 2017 at 12:26 PM, Andy Christianson <> wrote:
    > Hi All,
    > I am looking at MINIFI-350 and would like to implement some end-to-end
    > integration tests for minifi cpp. Essentially, the tests would:
    >   1.  Stand up a new minifi cpp docker container
    >   2.  Send test data to HTTP input ports on the container
    >   3.  Run data through a minifi flow
    >   4.  Receive output data to a HTTP endpoint
    >   5.  Verify output data according to some constraints (headers present,
    > hash of the content, etc.)
    > Most of this work, such as setting up a docker container and sending data
    > to it, can naturally be done with shell commands. As such, I’ve taken a
    > look at the bats [1] testing framework, which seems simple enough and is
    > very expressive.
    > Any thoughts or suggestions on test frameworks to use are appreciated.
    > [1]:

View raw message