Hi Deba,
You're observing the expected behaviour. The MockFileDatabase is an extremely dumb "database product". It matches input "SQL" strings (it doesn't even have to be actual SQL, it's just a random string to the MockFileDatabase) with static output result sets and/or update counts. It's completely static. It has no knowledge of the SQL language or storage or operations such as "sorting" or "grouping" or whatever.
You're expecting it to sort things. Based on what? The fact that you used the English words "SortByTitle" in a comment? How would that work? Using GPT-3? Where would it stop? Sorting? Grouping? Calculating window functions? Tracking state? Transactions? Locks? Concurrency? You know what a thing is called that does all of that? An actual database product :)
The MockFileDatabase is useful for a limited number of things, like:
- Unit testing stuff that's relatively query agnostic, such as mapping logic
- Quick and dirty prototyping (with an emphasis on "quick and dirty" and on "prototyping")
- Luring folks who google "mock jdbc" or "mock database" into using jOOQ. They came for the mocking (and I'll talk them out of it immediately again), but they're staying for how awesome jOOQ is :)
I'll repeat my suggestion to start using
https://www.testcontainers.org or any other means of integration testing instead of mocking. It is also mentioned here:
I'll make sure that disclaimer is copied to the MockFileDatabase's Javadoc and relevant section of the manual. For the reference, it is here:
Disclaimer: The general idea of mocking a JDBC connection with this jOOQ API is to provide quick workarounds, injection points, etc. using a very simple JDBC abstraction. It is NOT RECOMMENDED to emulate an entire database (including complex state transitions, transactions, locking, etc.) using this mock API. Once you have this requirement, please consider using an actual database instead for integration testing, rather than implementing your test database inside of a MockDataProvider.
You shouldn't build an entire database product based on this. It will never work. You'll never get it "right". Use an *actual* database product and run your queries against it. If you must: Use H2 or similar (which has its own set of issues, only recommended if you're also using H2 in production, or if you're supporting 10 different dialects anyway). If you can, use
https://www.testcontainers.org, and run everything against your actual production database product with actual sample data.
In case I still couldn't convince you to integration test your application instead, well, you'll have to provide the result sets for each of your possible queries, including:
- select .. from ... order by column
- select .. from ... order by column asc
- select .. from ... order by column desc
I hope this helps
Lukas