Re: JUnit-BDD

 I agree that lambdas can bring a lot of flexibility and usability to the
JUnit (rules, runners).

But what about exception testing?

All 3 currently popular ways mentioned in the
https://github.com/junit-team/junit/issues/722 have downsides:
1. @Test only allows you to test exception type and provides no way of
narrowing the scope of code that should throw an exception.
2. With ExpectedException you must declare a Rule and define exception
assertion before (and preferably just before) line of code that throws the
exception.
3. try-catch idiom is verbose and complicated.

With lambdas the following is possible (from
http://github.com/lpandzic/junit-bdd#ThrownExceptionsAssertion):

> when(deathStar.fireAt(alderaan));when(() -> deathStar.fireAt(alderaan)).then(thrownException -> {
>     assertThat(thrownException, is(instanceOf(TargetAlreadyDestroyedException.class)));
>     assertThat(thrownException.getMessage(), is(equalTo("Cannot fire at a destroyed " + alderaan)));});
>
> It allows you to specify the exact line that should throw an exception and
doesn't force you to define the assertion before it.

One problem that applies to all 3 currently supported ways of exception
testing in JUnit:
- there is no compilation error if you are testing for checked exception
that the tested code cannot throw.

For example lets say we have a class

class AClass {
        void aMethod() throws CheckedException {};
}

where CheckedException extends Exception.
If we write tests which test that aMethod throws a CheckedException and
later on we decide to change signature of aMethod to void aMethod() throws
CheckedException2 where CheckedException2 extends Exception then we will
get no compile time errors for our tests but those tests will surely fail.

JUnit-Bdd provides support for checked exception testing (
http://github.com/lpandzic/junit-bdd#ThrownCheckedExceptionsAssertion).


On Tue, Apr 22, 2014 at 7:19 PM, Colin Vipurs <[email protected]> wrote:

>
>
> It avoids the duplication between test description and method name as they
> become one.  Frameworks that support it (pretty much everything in the
> Scala and JavaScript world) allow much more flexibility for test
> descriptions, something I'd consider a big win
>
>
> On Sat, Apr 19, 2014 at 6:56 PM, Cédric Beust ♔ <[email protected]> wrote:
>
>>
>>
>> On Fri, Apr 18, 2014 at 10:41 AM, David Saff <[email protected]> wrote:
>>
>>
>>>
>>> I think that Java 8 lambdas open up a lot of opportunities to accomplish
>>> JUnit's goals in completely different ways.  I've been exploring with one
>>> approach myself on and off.  For one thing, to date, JUnit has relied on
>>> specially-named or annotated methods to accomplish the goal of succinctly
>>> associating a name with a block of code.  In Java 8, one can just do:
>>>
>>> addTest("Some test name", () -> {
>>>    // some code here
>>> })
>>>
>> I don’t see a lot of added value for this over
>>
>> @Test(description = "Some test name")public void shouldDoSomething) { ... }
>>
>> Actually, you lose a lot of expressivity that annotations give you for
>> free, such as adding configuration parameters to your test (e.g. specifying
>> concurrency settings, inheriting annotations from a base class, etc…).
>>
>> I’ve tried to find ways to leverage lambdas as well for testing and I’ve
>> come up completely empty so far.
>> --
>> Cedric
>>
>>
>
>
> --
> Maybe she awoke to see the roommate's boyfriend swinging from the
> chandelier wearing a boar's head.
>
> Something which you, I, and everyone else would call "Tuesday", of course.
>
>  
>