[
https://issues.apache.org/jira/browse/CALCITE-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573507#comment-16573507
]
Vladimir Sitnikov commented on CALCITE-2457:
--------------------------------------------
{quote}1) Perhaps it is personal preference but I find Truth / AssertJ to have
a much richer API for testing collections, maps, strings etc. Also error
reporting is human friendly :assertThat("foo").contains("bar"); // message: not
true that "foo" contains "bar"
assertTrue("foo".contains("bar")); // message: assertion failed{quote}
Is that IDE-friendly?
What I mean is I want IDE to display a clickable link that opens a DIFF window
in case there's a difference.
I don't care what messages are produced for simple cases like "expected true
got false", however diff link is a must to debug/analyze the results of "sql to
rel" or similar tests.
{quote}2) If you plan to use Kotlin then discussion changes a lot.{quote}
I've created https://issues.apache.org/jira/browse/CALCITE-2458 for that.
What's your take there?
Frankly speaking, I think we might want to try that for tests.
{quote} Overall this is a minor point and I don't feel religious about it.
Wanted to know the opinion of calcite devs on the topic.{quote}
Just a side note: Hamcrest has
[FeatureMatcher|http://hamcrest.org/JavaHamcrest/javadoc/1.3/org/hamcrest/FeatureMatcher.html],
however it is a bit wordy to write (for instance, I don't expect devs to
create a FeatureMatcher for a simple getter), and the results are not supported
for diff in IDEA.
Same goes for CombinedMatcher. The diff is not shown.
I think test output should be "diff friendly" rather than "human friendly".
{quote}assertTrue("foo".contains("bar")); // message: assertion failed{quote}
Apparently the code should be {{assertTrue(foo + " should contain bar",
foo.contains("bar"));}}. Of course that forces developer to duplicate the
logic, however I don't think that repeats very often.
Here's an example:
https://github.com/apache/calcite/pull/776/files#diff-ffa17851d5a9882f0391445f2fc04468R276
as you might see, simple {{assertSimplifies}} helper method is extremely
simple to use in tests, and it does produce proper exception messages. Did I
have to craft message for {{assertEquals}}? Of course, I did. However, that was
just ONE test line. That is why I think the ability to create Calcite-specific
helper methods/functions matters a lot, and I don't think
Truth/AssertJ/assertEquals differs much.
{quote}Overall this is a minor point and I don't feel religious about it.
Wanted to know the opinion of calcite devs on the topic.{quote}
Same for me, however I had no experience with the libraries you list :)
> Upgrade to JUnit 5
> ------------------
>
> Key: CALCITE-2457
> URL: https://issues.apache.org/jira/browse/CALCITE-2457
> Project: Calcite
> Issue Type: Improvement
> Reporter: Vladimir Sitnikov
> Assignee: Julian Hyde
> Priority: Major
>
> JUnit 5 brings multiple useful features so tests are easier to read and write.
> Is there something that blocks upgrading to JUnit 5?
> By upgrade I mean bumping up the dependency version and creating new tests
> with JUnit 5 features.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
