Hi, While it's nice to have easier tests, this does not really work for metrics as we use RxJava and AssertJ has no support for any reactive frameworks. The assertJ provides next to nothing in that context, as most of our implementation is reactive in behavior. There are two projects that have tried to improve situation with RxJava, one abandoned because the author thinks TestSubscriber is better and second one is quite incomplete. We don't currently write our tests well, that's true. We should be using TestSubscriber in multiple place instead of our current .toBlocking().lastOrDefault(null) (workaround). I really don't want the latter to be used more, since it's used in situations where it shouldn't be. Tests should be reactive just like our other code, and AssertJ can't provide that. - Micke ----- Original Message ----- From: "Joel Takvorian" <jtakvori(a)redhat.com&gt; To: "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; Sent: Tuesday, September 6, 2016 5:24:16 PM Subject: [Hawkular-dev] Assertj framework Hello, I'd like to propose the addition of the "assertj" lib in test scope for hawkular-metrics (and/or other modules). If you don't know it, assertj is basically a "fluent assertion framework". You write assertions like : assertThat(result) . extracting( DataPoint :: getTimestamp) . containsExactly( 0L , 1L , 5L , 7L , 10L ); It has a very rich collection of assertions, I find it particularly powerful when working on collections, whether they are sorted or not, whether they have nested objects or not. Also, the fact that it's "fluent" helps a lot when you write a test, because your IDE auto-completion will help you a lot to find what's the assertion you're looking for - something that is not so easy with hamcrest. I see it as a kind of virtuous cycle: tests are easier to write, easier to read, so you write more tests / better tests. Would you be ok to give it a try? If you want to read about it: official site is there http://joel-costigliola.github.io/assertj/ or an article that promotes it nicely : https://www.infoq.com/articles/custom-assertions or an example of file I'd like to push, if you're ok with assertj :) : https://github.com/jotak/hawkular-metrics/blob/72e2f95f7e19c9433ce44ee83d... Joel _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

Hi, Actually we should consider every synchronous processing part a bug ;), but there are some limitations on how we could do fully asynchronous streaming processing while using JAX-RS. As for testing libraries themselves, I think we have a mixture of too many testing libraries already, and something should go. At first we had JUnit + TestNG (for some old RHQ derived tests or something), then Mock, Mockito, luckily not PowerMockito, then for rest-tests we have Groovy testing libraries, for some load testing we have some Scala libraries and so on. Every time you write assertEquals, you can never be sure if it's "expected, actual" or "actual, expected". So, should we reduce before increasing? ;) - Micke ----- Original Message ----- From: "Joel Takvorian" <jtakvori(a)redhat.com&gt; To: "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; Sent: Tuesday, September 6, 2016 7:05:07 PM Subject: Re: [Hawkular-dev] Assertj framework There's maybe a need for both synchronous and asynchronous testing, no? It's true that I wasn't considering assertj under the angle of Observables, but does it really mean that we should eliminate the benefits of using a good library for all synchronous pieces of code? If I take the example of our collectors such as the "NumericDataPointCollector" : it's used in a RX transformation flow, but the class itself has nothing asynchronous, it has some methods that I think are complex enough to be put under synchronous unit tests. About TestSubscriber, I didn't know it, so thanks for sharing this! I'll try to use it instead of the "toBlocking" workaround in my last PR. On Tue, Sep 6, 2016 at 5:19 PM, Michael Burman < miburman(a)redhat.com > wrote: Hi, While it's nice to have easier tests, this does not really work for metrics as we use RxJava and AssertJ has no support for any reactive frameworks. The assertJ provides next to nothing in that context, as most of our implementation is reactive in behavior. There are two projects that have tried to improve situation with RxJava, one abandoned because the author thinks TestSubscriber is better and second one is quite incomplete. We don't currently write our tests well, that's true. We should be using TestSubscriber in multiple place instead of our current .toBlocking().lastOrDefault(null) (workaround). I really don't want the latter to be used more, since it's used in situations where it shouldn't be. Tests should be reactive just like our other code, and AssertJ can't provide that. - Micke ----- Original Message ----- From: "Joel Takvorian" < jtakvori(a)redhat.com > To: "Discussions around Hawkular development" < hawkular-dev(a)lists.jboss.org > Sent: Tuesday, September 6, 2016 5:24:16 PM Subject: [Hawkular-dev] Assertj framework Hello, I'd like to propose the addition of the "assertj" lib in test scope for hawkular-metrics (and/or other modules). If you don't know it, assertj is basically a "fluent assertion framework". You write assertions like : assertThat(result) . extracting( DataPoint :: getTimestamp) . containsExactly( 0L , 1L , 5L , 7L , 10L ); It has a very rich collection of assertions, I find it particularly powerful when working on collections, whether they are sorted or not, whether they have nested objects or not. Also, the fact that it's "fluent" helps a lot when you write a test, because your IDE auto-completion will help you a lot to find what's the assertion you're looking for - something that is not so easy with hamcrest. I see it as a kind of virtuous cycle: tests are easier to write, easier to read, so you write more tests / better tests. Would you be ok to give it a try? If you want to read about it: official site is there http://joel-costigliola.github.io/assertj/ or an article that promotes it nicely : https://www.infoq.com/articles/custom-assertions or an example of file I'd like to push, if you're ok with assertj :) : https://github.com/jotak/hawkular-metrics/blob/72e2f95f7e19c9433ce44ee83d... Joel _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

It's an interesting point, because the assertj way is precisely solving this issue with its english-like fluent writing : "Assert that <something> [is / contains / matches / whatever] <some other thing>". It's quite clear in this sentence that the subject is <actual>, complement is <expected>. And you never have to worry about it anymore. About the testing libraries, if we try to analyse that: JUnit: can't get rid of it, however the JUnit assertions could eventually be gradually replaced with the ones of the preferred framework if we want absolute homogeneity (but do we really want it?) TestNG: same as above, could be gradually replaced Mockito: still useful, not overlapping Testing in Groovy: my guess is that it was interesting to use groovy for on the fly objects declaration, maybe among other benefits. It seems to suits quite well for integration test, no? I haven't found the scala tests yet :) So the overlapping parts are more on JUnit / TestNG, and Assertj if we come to add it. But comparing to junit/testng, assertj clearly brings nice facilities as I described above. IMHO there's no need to rewrite every tests, adopting a new assertion framework can be done just progressively, without forcing anybody to adopt it right here right now. It's just giving some more tools that can be very appreciated some day on a particular situation.

Then again, JUnit5 is coming also with lambda support. Which is something we should migrate to as well. I don't know if it works with AssertJ, Google couldn't find any information. Lets try to avoid too many conflicts at least. - Micke ----- Original Message ----- From: "Joel Takvorian" <jtakvori(a)redhat.com&gt; To: "John Mazzitelli" <mazz(a)redhat.com&gt;, "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; Sent: Wednesday, September 7, 2016 10:42:37 AM Subject: Re: [Hawkular-dev] Assertj framework BTW groovy tests use junit assertions, so here also we could use assertj if we want to. On Wed, Sep 7, 2016 at 9:38 AM, Joel Takvorian < jtakvori(a)redhat.com > wrote: It's an interesting point, because the assertj way is precisely solving this issue with its english-like fluent writing : "Assert that <something> [is / contains / matches / whatever] <some other thing>". It's quite clear in this sentence that the subject is <actual>, complement is <expected>. And you never have to worry about it anymore. About the testing libraries, if we try to analyse that: JUnit: can't get rid of it, however the JUnit assertions could eventually be gradually replaced with the ones of the preferred framework if we want absolute homogeneity (but do we really want it?) TestNG: same as above, could be gradually replaced Mockito: still useful, not overlapping Testing in Groovy: my guess is that it was interesting to use groovy for on the fly objects declaration, maybe among other benefits. It seems to suits quite well for integration test, no? I haven't found the scala tests yet :) So the overlapping parts are more on JUnit / TestNG, and Assertj if we come to add it. But comparing to junit/testng, assertj clearly brings nice facilities as I described above. IMHO there's no need to rewrite every tests, adopting a new assertion framework can be done just progressively, without forcing anybody to adopt it right here right now. It's just giving some more tools that can be very appreciated some day on a particular situation. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev