[xwiki-devs] [Proposal] Use the "@Rule ExpectedException" strategy for asserting exception in unit tests
Hi devs, I’d like to propose that we use the strategy described at https://github.com/junit-team/junit/wiki/Exception-testing (thanks to Lyes for pointing out this page to me). For example: @Test public void sendSynchronousWithErrors() throws Exception { ... this.thrown.expect(MessagingException.class); this.thrown.expectMessage("Some messages have failed to be sent for the following reasons: " + "[[[errorsummary1],[errordescription1]][[errorsummary2],[errordescription2]]]"); this.mocker.getComponentUnderTest().send(Arrays.asList(message), session); } I feel it’s slightly better than our current idiom based on try/catch. One advantage is that we cannot forget to put the fail(). WDYT? Thanks -Vincent
Hi Vincent, There is a potential issue using such construction, but if you are aware, it look nicer than the try/catch, and I should have use it already form time to time when writing test for XWiki. The drawback is explained in this article: http://jakegoulding.com/blog/2012/09/26/be-careful-when-using-junit-expected... . The article propose an idea to avoid the issue, maybe we would like to implement it in our testing module ? On Sat, Jan 10, 2015 at 12:51 PM, [email protected] <[email protected]> wrote:
Hi devs,
I’d like to propose that we use the strategy described at https://github.com/junit-team/junit/wiki/Exception-testing (thanks to Lyes for pointing out this page to me).
For example:
@Test public void sendSynchronousWithErrors() throws Exception { ... this.thrown.expect(MessagingException.class); this.thrown.expectMessage("Some messages have failed to be sent for the following reasons: " + "[[[errorsummary1],[errordescription1]][[errorsummary2],[errordescription2]]]");
this.mocker.getComponentUnderTest().send(Arrays.asList(message), session); }
I feel it’s slightly better than our current idiom based on try/catch. One advantage is that we cannot forget to put the fail().
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
+1, although defining expectations is more like JMock than Mockito with respect to code style. I guess there's no way to verify the exception after invoking the component under test. Thanks, Marius On Sat, Jan 10, 2015 at 1:51 PM, [email protected] <[email protected]> wrote:
Hi devs,
I’d like to propose that we use the strategy described at https://github.com/junit-team/junit/wiki/Exception-testing (thanks to Lyes for pointing out this page to me).
For example:
@Test public void sendSynchronousWithErrors() throws Exception { ... this.thrown.expect(MessagingException.class); this.thrown.expectMessage("Some messages have failed to be sent for the following reasons: " + "[[[errorsummary1],[errordescription1]][[errorsummary2],[errordescription2]]]");
this.mocker.getComponentUnderTest().send(Arrays.asList(message), session); }
I feel it’s slightly better than our current idiom based on try/catch. One advantage is that we cannot forget to put the fail().
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+0, leaning to -0, mainly due to the lack of precision that could cause some not very obvious to debug test failures. What about this: https://code.google.com/p/catch-exception/ ? It seems to have a very flexible syntax and you don`t have (AFAICS) the drawback/issues pointed out by Denis. Thanks, Eduard On Wed, Jan 14, 2015 at 1:05 PM, Marius Dumitru Florea < [email protected]> wrote:
+1, although defining expectations is more like JMock than Mockito with respect to code style. I guess there's no way to verify the exception after invoking the component under test.
Thanks, Marius
On Sat, Jan 10, 2015 at 1:51 PM, [email protected] <[email protected]> wrote:
Hi devs,
I’d like to propose that we use the strategy described at https://github.com/junit-team/junit/wiki/Exception-testing (thanks to Lyes for pointing out this page to me).
For example:
@Test public void sendSynchronousWithErrors() throws Exception { ... this.thrown.expect(MessagingException.class); this.thrown.expectMessage("Some messages have failed to be sent for the following reasons: " + "[[[errorsummary1],[errordescription1]][[errorsummary2],[errordescription2]]]");
this.mocker.getComponentUnderTest().send(Arrays.asList(message), session); }
I feel it’s slightly better than our current idiom based on try/catch. One advantage is that we cannot forget to put the fail().
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
A nice review on the various ways of testing for exceptions: http://blog.codeleak.pl/2013/07/3-ways-of-handling-exceptions-in-junit.html (also talks about and links to a getting started post on catch-exception). Thanks, Eduard On Thu, Jan 15, 2015 at 11:42 AM, Eduard Moraru <[email protected]> wrote:
+0, leaning to -0, mainly due to the lack of precision that could cause some not very obvious to debug test failures.
What about this: https://code.google.com/p/catch-exception/ ?
It seems to have a very flexible syntax and you don`t have (AFAICS) the drawback/issues pointed out by Denis.
Thanks, Eduard
On Wed, Jan 14, 2015 at 1:05 PM, Marius Dumitru Florea < [email protected]> wrote:
+1, although defining expectations is more like JMock than Mockito with respect to code style. I guess there's no way to verify the exception after invoking the component under test.
Thanks, Marius
On Sat, Jan 10, 2015 at 1:51 PM, [email protected] <[email protected]> wrote:
Hi devs,
I’d like to propose that we use the strategy described at https://github.com/junit-team/junit/wiki/Exception-testing (thanks to Lyes for pointing out this page to me).
For example:
@Test public void sendSynchronousWithErrors() throws Exception { ... this.thrown.expect(MessagingException.class); this.thrown.expectMessage("Some messages have failed to be sent for the following reasons: " + "[[[errorsummary1],[errordescription1]][[errorsummary2],[errordescription2]]]");
this.mocker.getComponentUnderTest().send(Arrays.asList(message), session);
}
I feel it’s slightly better than our current idiom based on try/catch.
One advantage is that we cannot forget to put the fail().
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Thanks a lot for your replies. My opinion: * I didn’t know the “precision” issue pointed out by Denis so thanks about that and indeed it can be a problem in some cases * I made this proposal only because ExpectedException is part of JUnit and I thought it was the new best practice * I don’t like too much introducing a third-party library because it makes our tests non-standard (i.e. if you only know JUnit you’ll also need to understand that other library) and I don’t think the complexity introduced by a new library outweights the gains in this case. But it everyone feels strongly about introducing a new lib, I’m ok too. * I’m perfectly fine to continue using our try/catch idiom. Thanks -Vincent On 15 Jan 2015 at 10:48:19, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
A nice review on the various ways of testing for exceptions: http://blog.codeleak.pl/2013/07/3-ways-of-handling-exceptions-in-junit.html (also talks about and links to a getting started post on catch-exception).
Thanks, Eduard
On Thu, Jan 15, 2015 at 11:42 AM, Eduard Moraru wrote:
+0, leaning to -0, mainly due to the lack of precision that could cause some not very obvious to debug test failures.
What about this: https://code.google.com/p/catch-exception/ ?
It seems to have a very flexible syntax and you don`t have (AFAICS) the drawback/issues pointed out by Denis.
Thanks, Eduard
On Wed, Jan 14, 2015 at 1:05 PM, Marius Dumitru Florea < [email protected]> wrote:
+1, although defining expectations is more like JMock than Mockito with respect to code style. I guess there's no way to verify the exception after invoking the component under test.
Thanks, Marius
On Sat, Jan 10, 2015 at 1:51 PM, [email protected] wrote:
Hi devs,
I’d like to propose that we use the strategy described at https://github.com/junit-team/junit/wiki/Exception-testing (thanks to Lyes for pointing out this page to me).
For example:
@Test public void sendSynchronousWithErrors() throws Exception { ... this.thrown.expect(MessagingException.class); this.thrown.expectMessage("Some messages have failed to be sent for the following reasons: " + "[[[errorsummary1],[errordescription1]][[errorsummary2],[errordescription2]]]");
this.mocker.getComponentUnderTest().send(Arrays.asList(message), session);
}
I feel it’s slightly better than our current idiom based on try/catch. One advantage is that we cannot forget to put the fail().
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On my side I don't think we really need a rule on this. It's just good to know about new stuff, thanks. Also I'm not a big fan of adding a dependency just for that (but it's just a -0). On Thu, Jan 15, 2015 at 10:54 AM, [email protected] <[email protected]> wrote:
Thanks a lot for your replies.
My opinion:
* I didn’t know the “precision” issue pointed out by Denis so thanks about that and indeed it can be a problem in some cases * I made this proposal only because ExpectedException is part of JUnit and I thought it was the new best practice * I don’t like too much introducing a third-party library because it makes our tests non-standard (i.e. if you only know JUnit you’ll also need to understand that other library) and I don’t think the complexity introduced by a new library outweights the gains in this case. But it everyone feels strongly about introducing a new lib, I’m ok too. * I’m perfectly fine to continue using our try/catch idiom.
Thanks -Vincent
On 15 Jan 2015 at 10:48:19, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
A nice review on the various ways of testing for exceptions: http://blog.codeleak.pl/2013/07/3-ways-of-handling-exceptions-in-junit.html (also talks about and links to a getting started post on catch-exception).
Thanks, Eduard
On Thu, Jan 15, 2015 at 11:42 AM, Eduard Moraru wrote:
+0, leaning to -0, mainly due to the lack of precision that could cause some not very obvious to debug test failures.
What about this: https://code.google.com/p/catch-exception/ ?
It seems to have a very flexible syntax and you don`t have (AFAICS) the drawback/issues pointed out by Denis.
Thanks, Eduard
On Wed, Jan 14, 2015 at 1:05 PM, Marius Dumitru Florea < [email protected]> wrote:
+1, although defining expectations is more like JMock than Mockito with respect to code style. I guess there's no way to verify the exception after invoking the component under test.
Thanks, Marius
On Sat, Jan 10, 2015 at 1:51 PM, [email protected] wrote:
Hi devs,
I’d like to propose that we use the strategy described at https://github.com/junit-team/junit/wiki/Exception-testing (thanks to Lyes for pointing out this page to me).
For example:
@Test public void sendSynchronousWithErrors() throws Exception { ... this.thrown.expect(MessagingException.class); this.thrown.expectMessage("Some messages have failed to be sent for the following reasons: " + "[[[errorsummary1],[errordescription1]][[errorsummary2],[errordescription2]]]");
this.mocker.getComponentUnderTest().send(Arrays.asList(message), session);
}
I feel it’s slightly better than our current idiom based on try/catch. One advantage is that we cannot forget to put the fail().
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (5)
-
Denis Gervalle -
Eduard Moraru -
Marius Dumitru Florea -
Thomas Mortagne -
vincent＠massol.net