assertStream always passes about flink-spector

[lofifnc]

It's hard to debug this while only having access to a smartphone. My best guess is the test pipeline is never executed. But I can only confirm this if I have see the whole code of the test class. Preferably with imports. The second guess is the implementation of equals on the JSONObject class. I could have a better look into it on Tuesday. Am 18.05.2018 14:10 schrieb aschuhl <[email protected]>: I am attempting to write a unit test on my DataStream, but it is constantly passing. Here is my code: testEnv = DataStreamTestEnvironment.createTestEnvironment(1); createTestStream(Arrays.asList(eventStreamPayload)); DataStream<JSONObject> dataStream = createTestStream(Arrays.asList(eventStreamPayload)).flatMap(new myFlatMap()); TestSink<JSONObject> outputFormat = createTestSink(hasItems(new JSONObject(eventStreamPayload2))); dataStream.addSink(outputFormat); JSONObject jsonObject = new JSONObject(eventStreamPayload2); assertStream(dataStream, hasItems(jsonObject)); Now in the above case, eventStreamPayload and eventStreamPayload2 are different and myFlatMap() modifies eventStreamPayload as well. Yet the TestSink and assertStream is always passing. What am I a missing? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#78>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHE18P-_JEjOTYipgdEOymXKt_U7L3Mkks5tzro1gaJpZM4UEoL1>.

[aschuhl]

Yes myFlatMap() changes the structure of the eventStreamPayload, but no matter what I compared it to, it still passed.

So I switched to JUnit4 in case that was the problem and now see different results. The following asserts still always pass not matter what:

assertStream(dataStream, hasItems(jsonObject));
assertStream(dataStream,expectedRecords);

But the sink now fails and I don't know why. The line:

dataStream.addSink(outputFormat);

Fails with:

java.lang.AssertionError: 
Expected: (a collection containing <{"id":"aschuhl","type":"account","eId":"123456789","eType":"test"}>)
     but: a collection containing <{"id":"aschuhl","type":"account","eId":"123456789","eType":"test"}> 

But both collections seem the same to me.

[aschuhl]

Also here are the imports

import io.flinkspector.core.collection.ExpectedRecords;
import io.flinkspector.core.input.Input;
import io.flinkspector.core.input.InputBuilder;
import io.flinkspector.datastream.DataStreamTestBase;
import io.flinkspector.datastream.DataStreamTestEnvironment;
import io.flinkspector.datastream.functions.TestSink;
import org.apache.flink.streaming.api.datastream.DataStream;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.json.JSONObject;
import org.junit.jupiter.api.Test;
import java.util.Arrays;
import static org.hamcrest.Matchers.*;

public class test extends DataStreamTestBase {

[lofifnc]

The DataStreamTestBase has a lot of built in semantic sugar to reduce boiler plate code.
You've called some methods which the DataStreamTestBase normally hides. Also the TestBase only works with JUnit 4 for now.

        DataStream<JSONObject> dataStream = 
        createTestStream(Arrays.asList(eventStreamPayload)).flatMap(new myFlatMap());
        JSONObject jsonObject = new JSONObject(eventStreamPayload2);
        assertStream(dataStream, hasItems(jsonObject));

This should be all you need to setup the test.
assertStream already instantiates a TestSink and attaches it to the dataStream.
The TestSink validates the output this is why you see the AssertionError "too early".

The failed comparison between the two objects seems to stem from the equals Method on org.json.JSONObject, which only seems to do a reference comparison.
https://stackoverflow.com/questions/2253750/compare-two-json-objects-in-java

[Xeli]

import org.junit.jupiter.api.Test;

means junit 5 was used.

I had the same and 'fixed' it by calling initialize() and executeTest() manually. Are there 'plans' to switch or support junit5?

[lofifnc]

Yes there are plans but I have never used unit 5 myself and have to look into it.