Does FlexUnit 4 support the old naming conventions for testMethods, setUp and tearDown(), as an alternative to the new metadata? If not, please consider it. It would be much less work to migrate older tests if people didn't have to add [Test] everywhere just so FlexUnit can find the test methods.
It would be great if migrating a test case was, in most cases, a matter of removing the ''extends TestCase'', updating packages, and making setUp and tearDown public. Oh, and the asserts are a new style, but that can be made easier (I'll start another thread for that).
Does FlexUnit 4 support the old naming...Hi Robert,
you don麓t need to migrate your old FU1 tests. FU4 can run tests using both
syntaxs, the old and the new one. In fact a FU4 test suite can be made of
FU1, FU4 and Fluint testcases.
HTH
Xavi
Does FlexUnit 4 support the old naming...I'm aware that FU1 tests can be run without modification. Sorry for not being more clear--I'm talking about the situation where someone wants to migrate to FU4 in order to take advantage of new features. They've followed a consistent method naming convention (''testFoo'') in perhaps hundreds of methods. FU4 has a the JUnit 4-type metadata convention, but couldn't this be an option, rather than a mandatory replacement?
The reflection code to get all methods either starting with ''test'' or having metadata ''Test'' is quite simple:
var description:XML = describeType(object);
var methodNodes:XMLList = description.method.( @name.indexOf(''test'') == 0
聽聽 || (hasOwnProperty(''metadata'') %26amp;%26amp; metadata.@name == ''Test'') );
I understand that it would be simple, but my inclination here is to not mix those metaphors as I could see it becoming even more confusing.
Right now, the only way something runs as a test, regardless of the name is that the [Test] metadata appears above it. In Fluint, you could put the Test metadata there or you could name things test* and it tended to be confusing. A developer might have decided that a test should no longer run, so they removed the [Test] metadata, but the test would still execute because of the name. That generated a fair number of confused users.
What might be a nice change instead (if anyone is interested) is just to have a simple app that parses an FU1 style class and adds the metadata. Right now, you need to remove the extension from testcase, change the setup and teardown to now longer be overriden methods and decorate your methods with [Test] or [Before] and [After]. Seems like work an app could do better than a human.
Mike
%26gt;聽 they removed the [Test] metadata, but the test would still execute because of the name.
Ok. But why did they add [Test] to testFoo()? It's trying to use both conventions on the same method that's the problem there.
%26gt; Seems like work an app could do better than a human.
Agreed. And the app could change ''testFoo'' to ''foo'' (as an option, perhaps).
Robert
Sure.
I think it is because many of us have (for years) been puting test in front of our test method names. Even with the metadata, I still find myself doing that or searching for an alternative noun.
Mike
I like to use BDD-inspired words like ''when...then...should'' in my test method names, which tend to be phrases that read like use cases.
great tip.
This is a nice introduction to BDD naming guidelines:
http://dannorth.net/introducing-bdd
As a [X]
I want [Y]
so that [Z]
Title: Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don鈥檛 have to wait in line at the bank.
Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.
Scenario 1: Account is in credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
Another thing on test method names: Normally I try to avoid underscores for aesthetic and typing reasons, but with method_names_of_4_or_more_words, theyAreMoreReadableThanCamelCase.
nice one!
No comments:
Post a Comment