Skip to content

Add assertion library #132

Open
danielhep wants to merge 6 commits intoopentripplanner:mainfrom
danielhep:assertion-lib
Open

Add assertion library #132
danielhep wants to merge 6 commits intoopentripplanner:mainfrom
danielhep:assertion-lib

Conversation

@danielhep
Copy link
Contributor

With this PR I'm moving the assertion library that we are using in https://github.com/daniel-heppner-ibigroup/otp-deployment-tests to run checks against the returned itineraries from OTP to ensure we're getting reasonable results. I've tried to build a nice API that allows you to define the requirements for the itineraries in code.

@leonardehrenfried
Copy link
Member

Thanks for the PR.

If you would like this to be part of the main code, then I will do a pretty strict review and you will have to change a few things.

However, we can also add this as a separate Maven module and then it will be "yours" and I will not torture you with a flood of review comments.

What would you like to do?

@danielhep
Copy link
Contributor Author

A separate maven module is a good idea so I can have "ownership" over this feature and it's not your problem. I'll refactor it to do that.

That said, I'd appreciate any feedback on the code. I want to learn from this project and improve my Java code style.

Copy link
Member

@leonardehrenfried leonardehrenfried left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left comments for what I would like to see if it was "my" code. Since you're moving it into your own module, you may or may not take them on board.

Comment on lines +320 to +326
private static String routeShortName(Route route) {
return route == null ? null : route.getShortName();
}

private static String routeLongName(Route route) {
return route == null ? null : route.getLongName();
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of these static methods, I would wrap the route and add getters for the various fallback cases.

leg.distance());
}

private String describeCriteria(List<LegCriterion> criteriaSet) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be a method on LegCriterion.

return new ItineraryMatchResult(completeMatches, partialMatches, extraLegs, errors);
}

private String formatLegDescription(Leg leg) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would wrap the Leg and add this method there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we just add it to the Leg in the client package?

Comment on lines +110 to +111
assertThat(result.getPartialMatches().get(0).getMatchingCriteria()).contains("route '[10]'");
assertThat(result.getPartialMatches().get(0).getMissingCriteria()).contains("mode TRAM");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
assertThat(result.getPartialMatches().get(0).getMatchingCriteria()).contains("route '[10]'");
assertThat(result.getPartialMatches().get(0).getMissingCriteria()).contains("mode TRAM");
assertThat(result.getPartialMatches().getFirst().getMatchingCriteria()).contains("route '[10]'");
assertThat(result.getPartialMatches().getFirst().getMissingCriteria()).contains("mode TRAM");

Comment on lines +9 to +14
public class LegMatchingState {

private final Leg leg;
private final List<String> matchingCriteria = new ArrayList<>();
private final List<String> missingCriteria = new ArrayList<>();

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of an mutable state accumulator I would make the LegCriterion return a list of immutable results (some type of success/failure) and then the engine is responsible for accumulating the state.

That way the two responsibilities of

  • checking if the criterion matches
  • accumulating the state

are separate and it's easy to write more criterion, because they don't have to know to which collection they need to add their result.

@leonardehrenfried
Copy link
Member

Is this ready to merge or do you want to work on it some more?

@danielhep
Copy link
Contributor Author

danielhep commented Feb 27, 2026 via email

@leonardehrenfried
Copy link
Member

Is this now ready for review?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants