Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java tests: ease comparison of project grid with expected state #6372

Closed
wetneb opened this issue Feb 19, 2024 · 0 comments · Fixed by #6383
Closed

Java tests: ease comparison of project grid with expected state #6372

wetneb opened this issue Feb 19, 2024 · 0 comments · Fixed by #6383
Assignees
Labels
tests Improving test coverage and speed Type: Feature Request Identifies requests for new features or enhancements. These involve proposing new improvements.

Comments

@wetneb
Copy link
Sponsor Member

wetneb commented Feb 19, 2024

At the moment, many of our Java tests follow a pattern like this:

int merchantCol = project.columnModel.getColumnByName("merchant").getCellIndex();
int fruitCol = project.columnModel.getColumnByName("fruit").getCellIndex();
int priceCol = project.columnModel.getColumnByName("price").getCellIndex();
Assert.assertEquals(project.rows.get(0).getCellValue(merchantCol), "Katie");
Assert.assertEquals(project.rows.get(1).getCellValue(merchantCol), null);
Assert.assertEquals(project.rows.get(2).getCellValue(merchantCol), "John");
Assert.assertEquals(project.rows.get(0).getCellValue(fruitCol), "apple");
Assert.assertEquals(project.rows.get(1).getCellValue(fruitCol), "pear");
Assert.assertEquals(project.rows.get(2).getCellValue(fruitCol), "banana");
Assert.assertEquals(project.rows.get(0).getCellValue(priceCol), "1.2");
Assert.assertEquals(project.rows.get(1).getCellValue(priceCol), "1.5");
Assert.assertEquals(project.rows.get(2).getCellValue(priceCol), "3.1");

This is cumbersome, as it is very verbose and does not let the reader quickly grasp the shape of the expected result.

Proposed solution

Specify the expected state of a project after some operation by creating another project, in the expected state.
Introduce a test utility method to assert that two projects have equal contents.
Update the tests so that they go through such methods.

Alternatives considered

We could also make an assertion on an exported version of the project (such as CSV), but that would not be very readable and would introduce a dependency on an exporter which has nothing to do with the code being tested.

Additional context

Follow-up to #6371.

This will also help abstract away the way cell values are stored and accessed in a project, reducing the number of changes we need to make on the test suite for the new architecture developed in the 4.0 branch, as proposed here:
https://forum.openrefine.org/t/reproducibility-project-november-2023-report/1100/5

@wetneb wetneb added Type: Feature Request Identifies requests for new features or enhancements. These involve proposing new improvements. tests Improving test coverage and speed labels Feb 19, 2024
@wetneb wetneb self-assigned this Feb 19, 2024
wetneb added a commit to wetneb/OpenRefine that referenced this issue Feb 21, 2024
wetneb added a commit to wetneb/OpenRefine that referenced this issue Feb 24, 2024
wetneb added a commit that referenced this issue Mar 8, 2024
* Introduce test utility to compare project contents

Closes #6372.

* Move constant to EPSILON

* Apply suggestions from code review

Co-authored-by: Tom Morris <tfmorris@gmail.com>

* Fix compilation error

---------

Co-authored-by: Tom Morris <tfmorris@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tests Improving test coverage and speed Type: Feature Request Identifies requests for new features or enhancements. These involve proposing new improvements.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant