This may seem obvious but, for those running CFCUnit this tip may help
(if it isn't that obvious!)
We were doing a bit of testing and found that we had to write all of
this setup code in each of our tests... ie test variables etc that
each test required so our test had something like:
<cfset this.AccountFriendlyName = "Joe Bob's Home Line"/>
<cfset this.AccountIdentity = "joebob42">
<cffunction name="setUp" returntype="void" access="private">
<cfinvoke component="com.Application"
method="onApplicationStart"
returnvariable="tst">
<cfset this.Utility = CreateObject("component", "com.Utility")>
<cfset this.imap = CreateObject("component", "com.Imap") />
</cffunction>
Now that got annoying having to set this up for each of our tests
because I found that we were doing a bit of overlap (ie we had to set
this stuff up sometimes twice depending on which components we were
testing (service & DAO).
So I wrote another component (call it SetupTests.cfc) it extends the
testcase component (required for cfcunit) it does ALL the
configuration and calls setup and teardown then all of our test cases
extend the SetupTests.cfc so now all our configuration lives in one
CFC so we are sure that when our tests are running they are all using
the same variables. Ah, CF's CFC architecture is very nice indeed.
I am going to write up a blog post about this with a little more detail later.
-Steven
--
Steven Ross
web application & interface developer
http://www.zerium.com
[mobile] 404-488-4364
[fax] 928-484-4364
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
