assertError functionality to test for expected errors

4 views
Skip to first unread message

debug

unread,
May 4, 2009, 2:19:22 PM5/4/09
to Fluint Discussions
First off, congratulations on the decision to merge with FlexUnit.
I'm excited for it to come out.

I saw a question earlier about testing for an expected Error. I
created a global function assertError.as that simply takes a
description and a function to run. If the function does NOT throw an
Error then the assert fails. It would be nice to see this type of
assertion become part of the Fluint/FlexUnit framework.

// Global Function assertError.as
package
{
public function assertError(s:String, fn:Function):void
{
try
{
fn()
}
catch (e:Error)
{
return // OK, expected an error
}
throw new Error(s + "(): Expecting an error to be thrown")
}
}


// Example usage with a hypothetical immutable IList implementation
// that throws an Error on any method that would alter the list

var list:ImmutableIList = new ImmutableIList(1, 2, 3)

assertError("addItem", function()
{
list.addItem(666)
})

assertError("addItemAt", function()
{
list.addItemAt(2, 1)
})

assertError("removeItemAt", function()
{
list.removeItemAt(0)
})

assertError("removeAll", function()
{
list.removeAll()
})

Brian

unread,
May 4, 2009, 2:36:09 PM5/4/09
to Fluint Discussions
@debug - In the alpha released, there is support for class matching on
error types using the expects value in the [Test] metadata. For
example:

[Test(expects="my.custom.package.MyErrorClass")]
public myTestMethod() : void
{
...
}

Looks like your assertion method and the stuff built into the alpha
version address the same needs. I might be misunderstanding your
example however, can you help me out a bit? Mike's posted a quick
tour of the new stuff over on his blog @
http://blogs.digitalprimates.net/codeSlinger/index.cfm/2009/5/3/FlexUnit-4-in-360-seconds
if you're interested in other features as well.

Thanks for the input.

-Brian

debug

unread,
May 4, 2009, 3:44:12 PM5/4/09
to Fluint Discussions
I think you understand my post.

I'm new to AS3 coming from years of Java so I'm not as sophisticated
with using AS3's bracket metadata yet. Your proposed solution looks
superior to my workaround. In the Java world your solution would be
akin to JUnit 4 (when annotations/metadata were introduced) and mine
like JUnit 3.

Thanks for the quick response. Looking forward to when this is
available and stable.

On May 4, 1:36 pm, Brian <legr...@gmail.com> wrote:
> @debug - In the alpha released, there is support for class matching on
> error types using the expects value in the [Test] metadata.  For
> example:
>
> [Test(expects="my.custom.package.MyErrorClass")]
> public myTestMethod() : void
> {
>    ...
>
> }
>
> Looks like your assertion method and the stuff built into the alpha
> version address the same needs.  I might be misunderstanding your
> example however, can you help me out a bit?  Mike's posted a quick
> tour of the new stuff over on his blog @http://blogs.digitalprimates.net/codeSlinger/index.cfm/2009/5/3/FlexU...

Drew Bourne

unread,
May 4, 2009, 7:43:53 PM5/4/09
to fluint-di...@googlegroups.com
@debug Using assertThat(), throws(), and other matchers from hamcrest
is another way to achieve fine grained testing of Errors.

[Test]
public function addingItemToImmutableListThrowsIllegalOperationError():void {
assertThat(function():void {
immutableList.addItem(new Item());
}, throws(allOf(instanceOf(IllegalOperationError),
hasPropertyWithValue('message', equalTo('Unable to modify immutable
list')))));
}

The hamcrest matchers are included with the alpha of FlexUnit, or
available at http://github.com/drewbourne/hamcrest-as3/tree/master if
you want to start using them with earlier versions of Fluint or
FlexUnit.

cheers,
Drew
Reply all
Reply to author
Forward
0 new messages