Re: [CFCDev] Unit Test for DAO

Paul Kenney Tue, 29 Nov 2005 19:19:22 -0800

Think of the setUp() and tearDown() methods as user-defined constructors and destructors. In CF we have the ability to initialize CFCs by simply placing code outside of the methods. While this works and has its uses, in most cases it is recommended practice to have an init() method that must be called as a constructor.

In TestCase classes, the setUp() method is called at a very specific time within the lifecycle of the test by the testing framework itself. Since it is called *explicitly* by the framework, it is run inside a try/catch block. If any exceptions are thrown by the "setUp" method--and it happens from time to time--those exceptions will be properly captured by the framework and reported to the user via the test runner application's report. One of the problems of not placing initialization code inside a method that is called *after* the object is completely instantiated is that any exceptions that get thrown by that code will prevent the object from being created. CreateObject() simply drops it and throws its own exception saying it could not find the specified component, and this is not helpful at all.

As far as why a different object is created for each test, let me explain. It is a very fundamental principle in unit testing that each test is completely isolated from one another. This means that changes made in one test should not be visible in another. Having a separate instance of the TestCase for each test is just one way of reinforcing this principle by making sure that you really have to try to have one test affect another.

I hope that this answers some of your questions and address your concerns about these things.

Paul

On 11/29/05, Jeff Chastain <[EMAIL PROTECTED] > wrote:

My understanding was that the setUp function was run before every test and the tearDown function was run after every test. The problem is, if the test case is instantiated for every test, then the setUp function is really pretty useless as anything in the global area of the component will be executed before the test anyways. I am not 100% sure why the test case is instantiated for each test ... if it were not, then the setUp and tearDown functions would make perfect sense.

-- Jeff

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Brian Kotek
Sent: Tuesday, November 29, 2005 7:57 PM

To: CFCDev@cfczone.org
Subject: Re: [CFCDev] Unit Test for DAO

Agreed, isn't the whole point of setUp() that it only be run once, when the TestCase is instantiated? Or am I wrong and setUp() is, in other xUnit frameworks, run prior to every test?

On 11/29/05, Jeff Chastain <[EMAIL PROTECTED]> wrote:

Paul -

The more I look at this, the less reason I can see for the setUp method to exist. Based upon our conversation before, if the test component is instantiated for each test, what is the difference in putting the variables in the 'global' section of the cfc vs. in the setup method?

-- Jeff

From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Paul Kenney
Sent: Tuesday, November 29, 2005 2:11 PM
To: CFCDev@cfczone.org
Subject: Re: [CFCDev] Unit Test for DAO

Jeff,


<cfset variables.dsn = 'listManager_mySQL' />


<cfset variables.testData = structNew() />
<cfset variables.testData.id = '' />
<cfset variables.testData.name = 'Test Property'/>
<cfset variables.testData.dataType = 'String' />
<cfset variables.testData.required = true />
<cfset variables.testData.defaultValue = '' />
<cfset variables.testData.currentValue = '' />

One thing I noticed right away is that this code should go inside the setUp() method. Didn't have a chance to look at the rest too closely.

--
Paul Kenney
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.pjk.us ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ----------------------------------------------------------

You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ----------------------------------------------------------

You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org

--
Paul Kenney
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.pjk.us ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org

Re: [CFCDev] Unit Test for DAO

Reply via email to