Hi all.
I've worked on a little tool to try to automatize a bit the conversion of
assertions to assertj https://github.com/slinkydeveloper/assertj-migrator.
It's not perfect, but it's an attempt to unify a bit the test codebase.
We applied it to flink-table modules and it worked like a charm,
Hi all,
I took a close look at assertj and found there are two concepts for writing
tests with two entry points interfaces: WithAssertions for normal style and
BDDAssertions for BDD style. I would not suggest using them in one project
simultaneously. Since all related work done previously were
Definitely +1 from me as well. Otherwise backporting tests (accompanying
fixes) would consume significant time.
On Fri, Dec 3, 2021 at 11:42 AM Till Rohrmann wrote:
> I think this is a very good idea, Matthias. +1 for backporting the jassert
> changes to 1.14 and 1.13 if possible.
>
> Cheers,
>
I think this is a very good idea, Matthias. +1 for backporting the jassert
changes to 1.14 and 1.13 if possible.
Cheers,
Till
On Fri, Dec 3, 2021 at 11:38 AM Matthias Pohl
wrote:
> Currently, we only added the jassert to the master branch. I was wondering
> whether we could backport the
Currently, we only added the jassert to the master branch. I was wondering
whether we could backport the corresponding PR [1] to release-1.14 and
release-1.13, too. Otherwise, we would have to implement tests twice when
providing PRs with new tests that need to be backported: The jassert
version
As @Matthias Pohl mentioned, I agree that no1 is
to end up with consistency
regarding the assertions in our tests, but I also like how those assertions
shape up with the AssertJ approach.
On Thu, Nov 25, 2021 at 9:38 AM Francesco Guardiani
wrote:
> This is the result of experimenting around
This is the result of experimenting around creating custom assertions for Table
API types
https://github.com/slinkydeveloper/flink/commit/
d1ce37a62c2200b2c3008a9cc2cac91234222fd5[1]. I will PR it once the two PRs in
the
previous mail get merged
On Monday, 22 November 2021 17:59:29 CET
Hi all,
Given I see generally consensus around having a convention and using
assertj, I propose to merge these 2 PRs:
* Add the explanation of this convention in our code quality guide:
https://github.com/apache/flink-web/pull/482
* Add assertj to dependency management in the parent pom and link
Agree. Clarifying once more what our preferred option is here, is a good
idea. So, +1 for unification. I don't have a strong opinion on what
framework to use. But we may want to add this at the end of the discussion
to our documentation (e.g. [1] or maybe the PR description?) to make users
aware
I'm also +1 both for unification and specifically for assertJ.
I think it covers a wide variety of assertions and as Francesco mentioned
it's easily extensible, so that
we can create custom assertions where needed, and avoid repeating test code.
On Tue, Nov 16, 2021 at 9:57 AM David Morávek
I don't have any strong opinions on the asserting framework that we use,
but big +1 for the unification.
Best,
D.
On Tue, Nov 16, 2021 at 9:37 AM Till Rohrmann wrote:
> Using JUnit5 with assertJ is fine with me if the community agrees. Having
> guides for best practices would definitely help
Using JUnit5 with assertJ is fine with me if the community agrees. Having
guides for best practices would definitely help with the transition.
Cheers,
Till
On Mon, Nov 15, 2021 at 5:34 PM Francesco Guardiani
wrote:
> > It is a bit unfortunate that we have tests that follow different
>
> It is a bit unfortunate that we have tests that follow different patterns.
This, however, is mainly due to organic growth. I think the community
started with Junit4, then we chose to use Hamcrest because of its better
expressiveness.
That is fine, I'm sorry if my mail felt like a rant :)
>
JUnit5 migration is currently mostly prepared. The rules are being migrated
[1] and Hang and Qingsheng have migrated most tests in their branch afaik
(Kudos to them!).
Using assertj would make migration easier as it's independent of the JUnit
version. But the same can be said about hamcrest,
Thanks for starting this discussion Francesco. I think there is a lot of
value in consistency because it makes it a lot easier to navigate and
contribute to the code base. The testing tools are definitely one important
aspect of consistency.
It is a bit unfortunate that we have tests that follow
I agree on AssertJ being so much more expressive that I think it would be
worth switching. However, we should be careful not to solve the issue of
too many assertion frameworks by adding another one on top of everything
(but also realizing that we cannot easily migrate all tests in one go).
On
For what it's worth, I recently rewrote all of the tests in flink-training
to use assertj, removing a mixture of junit4 assertions and hamcrest in the
process. I chose assertj because I found it to be more expressive and made
the tests more readable.
+1 from me
David
On Fri, Nov 12, 2021 at
Hi all,
I wonder If we have a convention of the testing tools (in particular
assertions) to use in our tests. If not, are modules free to decide on a
convention on their own?
In case of table, we have a mixed bag of different assertions of all kinds,
sometimes mixed even in the same test:
-
18 matches
Mail list logo
