Re: JUnit-BDD

I have to say I love the intercept method used in Scalatest:

val s = "hi"
val thrown = intercept[IndexOutOfBoundsException] {
  s.charAt(-1)
}

// assert something about thrown

I use this all the time.

Matthew Farwell.




2014-04-22 21:46 GMT+02:00 Lovro Pandzic <[email protected]>:

>
>
> 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.
>>
>>
>  
>