Include first test to Jakarta Data Core [Part 1] #1318

otaviojava · 2026-01-06T19:53:53Z

This pull request introduces a set of new entity classes, repositories, and supporting utilities for standalone data-driven tests in the TCK. It also adds AssertJ as a test dependency and provides a custom annotation for parameterized assertions. The changes focus on enabling richer test scenarios with entities like Fruit and Vehicle, their suppliers, and repositories, as well as improving test metadata and assertion capabilities.

Entity and Repository Additions

Added new entity classes: Fruit, Vehicle, and supporting enum Transmission, each with fields, constructors, and standard methods for equality and string representation. [1] [2] [3]
Introduced repository interfaces: FruitRepository and VehicleRepository, providing query methods for CRUD and filtering operations on the respective entities. [1] [2]
Added projection record VehicleSummary for summarizing vehicle data in queries.

Data Suppliers for Parameterized Tests

Created supplier classes FruitSupplier and VehicleSupplier to provide lists of sample entities for parameterized tests, backed by static lists and utility methods for entity creation. [1] [2]
Added an abstract base class AbstractSupplier implementing both Supplier<List<T>> and JUnit's ArgumentsProvider for seamless integration with parameterized testing.

Test Framework and Metadata Enhancements

Added a custom annotation ParametizedAssertion for tracking test metadata, such as GitHub issue/PR references and assertion strategies, to improve test documentation and traceability.
Updated tck/pom.xml to include AssertJ as a dependency for fluent assertions in tests, and defined its version in the properties section. [1] [2]

…f intermediate variables

…uralNumbers

…uracy

…nerator

…eListSupplier implementation

…ation

…s, include AssertJ dependency in build file

…a-driven test assertions

…tities test for enhanced metadata and parameterized execution

… with corresponding tests in JakartaQueryTests

…ehicle entity

…ding test

…erator

…ts with dynamic parameter handling - Introduced several query methods in `FruitRepository` for filtering by name, quantity, and ranges. - Updated `JakartaQueryTests` to adjust database keyword support checks and added a nested class for dynamic parameters.

…Tests setup - Introduced `deleteAll` method in `FruitRepository` for bulk deletion. - Updated `JakartaQueryTests` to use `fruitRepository.deleteAll` in test setup for data cleanup.

…rtaQueryTests with additional comparisons

…filtering

…ltering and update JakartaQueryTests assertions

… JakartaQueryTests - Updated `FruitRepository` methods to use accurate parameter annotations and improve query logic. - Added parameterized tests for AND/OR queries in `JakartaQueryTests` with comprehensive assertions.

njr-11

There is too much combined in a single PR. Parts of this are unrelated and should be reviewed separately.

For example, alterations to existing TCK tests, which need to be better understood on their own,

Removed an unused or incorrect WHERE clause from a query in NaturalNumbers.java to clean up the code.

The WHERE clause is not unused because you had to alter test assertions after removing it. I don't know what would be incorrect about it. If you are seeing an error, we need to explore why. Are there additional limitations of NoSQL databases (other than Key-Value and Column, which are already excluded) causing problems here? If so, we should add and document an appropriate exclusion.

I haven't looked at the other parts other than seeing that there is a Faker class. Hopefully that does not produce random data. We should avoid randomness so that TCK failures reproduce every time the tests run. Otherwise someone can just keep retrying until they are lucky and then claim compliance.

- Enhanced `numberPage` query with additional filtering condition. - Updated `EntityTests` assertions to reflect refined query results and improve consistency.

otaviojava · 2026-01-07T07:06:55Z

@njr-11 I've removed the natural numbers, and I will move it to another PR.

I haven't looked at the other parts other than seeing that there is a Faker class. Hopefully that does not produce random data.

This part of the code uses data-driven testing. Faker is only used to generate input parameters; once those parameters are provided, test execution and assertions are fully deterministic.

If this is a concern, I’m happy to change it. Still, when the focus is on validating behavior across data variations, a data-driven approach is, in my view, the most appropriate and practical choice.

…itSupplier with static data - Removed `AbstractListSupplier` class and `DataFaker` dependency. - Renamed `FruitListSupplier` to `FruitSupplier` and replaced dynamic fruit generation with static list initialization.

… FruitSupplier to use static fruit data

…pplier, remove unused imports

…and add FruitSummary record

…and add a new test for projection

…treamline deployment configuration

… assertions

otaviojava · 2026-01-07T19:39:10Z

That is something to discuss in a separate issue and get agreement on before trying to implement. I thought @KyleAure did an excellent job with the approach we currently have for the TCK.

Yes, @KyleAure did an amazing job! And I never said anything different!

My point is: we need to keep updating based on the context and challenges that we have now!

…ding test

… sorting checks

otaviojava · 2026-01-07T19:45:48Z

@njr-11, how about now?

We got 7 files.

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/JakartaQueryTests.java

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/FruitPopulator.java

KyleAure · 2026-01-07T19:53:18Z

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/JakartaQueryTests.java

+
+@Standalone
+@AnyEntity
+@ReadOnlyTest


Similar to previous review comment, you only need to add the @ReadOnlyTest annotation if you are using a repository from the read.only package. See: https://github.com/jakartaee/data/blob/main/tck/src/main/java/ee/jakarta/tck/data/framework/arquillian/extensions/TCKArchiveProcessor.java#L67-L71

I've removed this annotation once, I will include operations that will change the data.

KyleAure · 2026-01-07T20:09:21Z

FWIW: I agree using modernized testing strategies like parameterized tests is valid, but we have to make sure we have a valid use case to do it. Before your recent changes I was going to comment about the fact that in each test case you attempted to persist the same list of entities, which would have caused EntityExistsException(s) had it been run against a database.

Also remember that many Jakarta users look at the TCK tests to see how to use entities/repositories/queries so the more test abstraction we add the less these tests resemble what user might actually write in their application and therefore be poor examples of valid use cases.

njr-11

Thanks - I completed reviewing the tests. I found a lot of issues with the allowances, usually stating the wrong reason and sometimes applying to database types that are inconsistent with what we already have in the Data TCK.

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/JakartaQueryTests.java

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/Transmission.java

…ency

…unctionality

…for query checks

…aner code

…ery checks

…pabilities for query operations

otaviojava · 2026-01-08T08:15:43Z

@njr-11 I've updated all the comments

otaviojava · 2026-01-08T08:18:59Z

@KyleAure, I've changed what you said. Could you check it as well?

KyleAure · 2026-01-08T15:56:20Z

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/JakartaQueryTests.java

+import java.util.logging.Logger;
+
+@Standalone
+@AnyEntity


Suggested change

@AnyEntity

@ReadOnlyTest

@AnyEntity

I think something got mis-interpreted with my previous suggestions. Having the @ReadOnlyTest annotation was a good thing, but the issue was that you didn't actually put the classes in the read only package.

Add back in the annotation, but move the entity and repository to the read only package.

But @KyleAure, the next commit will write, those are only the first 10 of 50 tests.

IMHO: it does not make sense to move to ReadOnly, and the next PR move it again.

That was not clear to me based off of how you were using the repository in this PR. (I cannot predict the future :D)

However, the more performant thing to do would be to have one repository (Fruits) that only does read operation testing and keep it read only, then have another repository (Vegetables?) that does read/write operations.

That way on a per-test basis you can ensure that whatever you wrote to the read/write repository is undone before moving onto the next test?

I cannot predict the future :D

My bad :)

Can I use this Fruit entity for both writing and reading?

Or should I have one entity for reading operations and one for writing operations?

That is not clear to me.

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/JakartaQueryTests.java

otaviojava · 2026-01-08T19:16:22Z

@njr-11 also, don't forget to review it as well.

njr-11

It looks like my prior review comments were blasted away, so I tried to go through everything again and post comments.

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/JakartaQueryTests.java

njr-11 · 2026-01-08T19:30:43Z

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/JakartaQueryTests.java

+                    .containsAll(fruits);
+        } catch (UnsupportedOperationException exp) {
+            if (type.isKeywordSupportAtOrBelow(DatabaseType.COLUMN)) {
+                // Column and Key-Value databases might not be capable of find all elements.


I don't see any language in the spec that makes this allowance

If in both cases we can find by ID, and we are running a query without ID, then we won't be able to execute this query.

The point is that the specification doesn't allow for the exemption. You need spec language to cover that. I just added that for you in #1319 , after which this one should now be okay.

njr-11 · 2026-01-08T19:31:34Z

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/JakartaQueryTests.java

+                    .containsAll(expected);
+        } catch (UnsupportedOperationException exp) {
+            if (type.isKeywordSupportAtOrBelow(DatabaseType.COLUMN)) {
+                // Column and Key-Value databases might not be capable of find all elements.


Again, I haven't been able to find any language in the spec allowing this to be ignored for key-value and column

@njr-11, do you prefer to update the query and put in (ids) instead?

See the discussion of my previous comment. I proposed adding spec language in #1319 that would make the allowance here valid.

njr-11 · 2026-01-08T19:33:35Z

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/JakartaQueryTests.java

+                    .allMatch(fruit -> !fruit.getName().equals(sample.getName()));
+        } catch (UnsupportedOperationException exp) {
+            if (type.isKeywordSupportAtOrBelow(DatabaseType.COLUMN)) {
+                // Column and Key-Value databases might not be capable querying by attribute that is not a key.


Comparing an attribute that is not the key is making a lot of these very basic tests not apply to Column and Key-Value. I recommend we switch the repository method so that its JCQL query compares the key value instead. Then we won't need to skip so many tests.

I can do it, but from the user perspective, why not use the method that we have built in, such as findById?

I am fine to update it, but I would search non-ID attributes.

Please, let me know what you think, thus, I can update as you wish.

I can do it, but from the user perspective, why not use the method that we have built in, such as findById?

Because this is a TCK test of query language, not a user example that limits itself to the easiest way to use the API. I'm pretty sure we already have TCK tests for findById versus the valid query language WHERE id = :id which is probably not covered anywhere.

…aQueryTests.java Co-authored-by: Nathan Rauh <[email protected]>

otaviojava added 21 commits January 6, 2026 12:54

test: refactor CardinalNumber stream assertions for clarity and use o…

31ffba2

…f intermediate variables

refactor: remove unused filter condition from numberPage query in Nat…

d5bc2e1

…uralNumbers

test: update expected values in EntityTests stream assertions for acc…

2426fa9

…uracy

feat: add Vehicle entity with properties, methods, and Faker-based ge…

409fc4b

…nerator

feat: introduce AbstractSupplier and AbstractListSupplier with Vehicl…

9db1a8e

…eListSupplier implementation

feat: add DataFaker library and Transmission enum for test data gener…

82e254b

…ation

feat: add VehicleRepository and JakartaQueryTests for query operation…

2abf8ab

…s, include AssertJ dependency in build file

feat: add ParametizedAssertion annotation to support metadata for dat…

5cd1dba

…a-driven test assertions

test: add ParametizedAssertion and ArgumentsSource to shouldFindAllEn…

c921320

…tities test for enhanced metadata and parameterized execution

feat: add ascending and descending query methods to VehicleRepository…

63cf2f5

… with corresponding tests in JakartaQueryTests

chore: add missing Comparator import in JakartaQueryTests

5c001bc

feat: add VehicleSummary record with factory method for summarizing V…

6f865de

…ehicle entity

feat: add projection query method to VehicleRepository with correspon…

0ff9f2e

…ding test

feat: add Fruit entity with repository, supplier, and Faker-based gen…

f74aaff

…erator

feat: add deleteAll method to FruitRepository and update JakartaQuery…

90f631e

…Tests setup - Introduced `deleteAll` method in `FruitRepository` for bulk deletion. - Updated `JakartaQueryTests` to use `fruitRepository.deleteAll` in test setup for data cleanup.

feat: update FruitRepository query method parameters and enhance Jaka…

3415be7

…rtaQueryTests with additional comparisons

feat: add new query methods to FruitRepository for name and quantity …

80175f4

…filtering

feat: add new query method to FruitRepository for name or quantity fi…

5dfab66

…ltering and update JakartaQueryTests assertions

refactor: remove duplicate query method in FruitRepository for clarity

4c4df3a

otaviojava requested a review from njr-11 January 6, 2026 19:54

njr-11 reviewed Jan 6, 2026

View reviewed changes

otaviojava added 2 commits January 7, 2026 06:56

feat: refine pagination queries and update EntityTests assertions

011ab6b

- Enhanced `numberPage` query with additional filtering condition. - Updated `EntityTests` assertions to reflect refined query results and improve consistency.

refactor: remove DataFaker dependency from starter POM files

7b5f692

otaviojava added 4 commits January 7, 2026 07:23

refactor: remove DataFaker dependency from POM file

0b57a64

feat: implement VehicleSupplier with static vehicle data and refactor…

5fada9a

… FruitSupplier to use static fruit data

refactor: update JakartaQueryTests to use VehicleSupplier and FruitSu…

fe033fb

…pplier, remove unused imports

otaviojava added 6 commits January 7, 2026 19:33

refactor: update FruitRepository to query Fruits instead of Vehicles …

8cb8602

…and add FruitSummary record

refactor: update JakartaQueryTests to simplify strategy descriptions …

a5eec21

…and add a new test for projection

refactor: update JakartaQueryTests to simplify strategy descriptions …

271c840

…and add a new test for projection

refactor: update JakartaQueryTests to remove Vehicle references and s…

1579d54

…treamline deployment configuration

refactor: update Fruit hashCode method and simplify JakartaQueryTests…

bb1515e

… assertions

refactor: update Fruit hashCode method and simplify JakartaQueryTests…

900d60b

… assertions

otaviojava added 4 commits January 7, 2026 19:41

refactor: update Fruit hashCode method to use Objects.hash

897d8c2

refactor: update Fruit hashCode method to use Objects.hash

04c4039

refactor: correct method name in FruitRepository and update correspon…

7c0f436

…ding test

refactor: update JakartaQueryTests to handle COLUMN database type for…

58d8a23

… sorting checks

KyleAure reviewed Jan 7, 2026

View reviewed changes

njr-11 requested changes Jan 7, 2026

View reviewed changes

otaviojava added 8 commits January 8, 2026 07:50

refactor: update JakartaQueryTests to unify assertion IDs for consist…

43794bd

…ency

refactor: rename FruitPopulator and update package structure for clarity

1190c3e

refactor: add FruitRepository import to FruitPopulator for improved f…

a7087ee

…unctionality

refactor: update JakartaQueryTests to handle KEY_VALUE database type …

2fecffc

…for query checks

refactor: remove unsed class

490b71b

refactor: remove unnecessary blank lines in JakartaQueryTests for cle…

6d9968a

…aner code

refactor: update JakartaQueryTests to use COLUMN database type for qu…

4238a53

…ery checks

refactor: update comments in JakartaQueryTests to clarify database ca…

3a3d35d

…pabilities for query operations

refactor: remove unused ReadOnlyTest annotation from JakartaQueryTests

6931a0b

KyleAure reviewed Jan 8, 2026

View reviewed changes

njr-11 reviewed Jan 8, 2026

View reviewed changes

Update tck/src/main/java/ee/jakarta/tck/data/standalone/entity/Jakart…

30526a6

…aQueryTests.java Co-authored-by: Nathan Rauh <[email protected]>

Include first test to Jakarta Data Core [Part 1] #1318

Are you sure you want to change the base?

Include first test to Jakarta Data Core [Part 1] #1318

Conversation

otaviojava commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Entity and Repository Additions

Data Suppliers for Parameterized Tests

Test Framework and Metadata Enhancements

Uh oh!

njr-11 left a comment

Choose a reason for hiding this comment

Uh oh!

otaviojava commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

otaviojava commented Jan 7, 2026

Uh oh!

otaviojava commented Jan 7, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KyleAure commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

njr-11 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

otaviojava commented Jan 8, 2026

Uh oh!

otaviojava commented Jan 8, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

otaviojava Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

otaviojava commented Jan 8, 2026

Uh oh!

njr-11 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

otaviojava commented Jan 6, 2026 •

edited

Loading

otaviojava commented Jan 7, 2026 •

edited

Loading

KyleAure commented Jan 7, 2026 •

edited

Loading

otaviojava Jan 8, 2026 •

edited

Loading