r2dbc / r2dbc-spi

TestKit executes a query which allows a database to return rows in any order:

r2dbc-spi/r2dbc-spi-test/src/main/java/io/r2dbc/spi/test/TestKit.java

Line 872 in a865624

SELECT_VALUE("SELECT value FROM test"),

This can yield inconsistent results when the test table has more than one row. An example is TestKit.transactionCommit() which executes the query after two rows have been inserted:

r2dbc-spi/r2dbc-spi-test/src/main/java/io/r2dbc/spi/test/TestKit.java

Line 748 in a865624

    
           .concatWith(Flux.from(connection.createStatement(expand(TestStatement.SELECT_VALUE))

A database may execute this query by returning rows in the following order: 200, 100. This causes the test fail when expecting rows in the order of: 100, 200:

r2dbc-spi/r2dbc-spi-test/src/main/java/io/r2dbc/spi/test/TestKit.java

Line 761 in a865624

.expectNext(Arrays.asList(100, 200)).as("values from select")

To ensure that rows are returned in a consistent order, the query could use an ORDER BY clause:

        SELECT_VALUE("SELECT value FROM test ORDER BY value"),

Good catch. We don't have any statements that incorporate ORDER BY. We should only assert that the expected items are returned without considering their order. I'd suggest to switch to sets. That is extractColumns to return Mono<Collection<Integer>> backed by a Set implementation and switch assertions to something along the lines of expectNext(new HashSet<>(Arrays.asList(100, 200, 300))). Since our baseline is Java 8, we might want to have a utility method for convenient set creation.

Agreed: I think a Set will work just as well, without having to introduce ORDER BY.

FYI: I'm starting work on the pull request now.

TestKit.Statement.SELECT_VALUE Returns Rows in Inconsistent Order