mxunit newbie / coldfusion builder

[DCL]

I'm getting started with TDD and mxunit, and things are working fine
when I run tests directly from a cfm page. I can't get any tests to
run from the Eclipse plugin which I've installed in Coldfusion
Builder.

This is probably for one of two reasons:

(1) Mxunit plugin doesn't work in Coldfusion Builder, which is implied
on the site but not stated explicitly anywhere

or

(2) Something is wrong with my preferences or project setup.

Can somebody either confirm or deny #1? If #1 is false, can you help
me figure out what's misconfigured?

The error I'm getting is "Could not find the Coldfusion Component or
Interface workspace.webservice.mxunit.whatever"

("workspace" is the name of my workspace folder; "webservice" is the
name of my project folder.)

I've tried a number of different configurations of the preference for
webroot and component root, but nothing seems to change the error
message.

Any suggestions?

[Marc Esher]

DCL,
the plugin works fine in builder. I'd suggest clicking the green
question mark button on the plugin view and reading the first few
pages of the help files. those should explain exactly what you need to
do, configuration-wise. basically, you either need to correctly
configure your 'webroot' preference in window -- preferences -- mxunit
(probably to something like c:\wherever\workspace) or set the cfc
path property on your project (right click, properties, mxunit... then
type "webservice" as the cfcpath.

definitely read those Help pages, though, so that you understand
what's going on. bottom line: the plugin needs to figure out the
component path for your files, and the preference or property
(depending on your needs -- the distinction is explained in the Help)
is what the plugin uses to do so.

Good luck, and please let me know if you're still having troubles
after reading those docs.

Welcome to unit testing! Hopefully this little initial setup pain is
the worst of it.

Marc

> --
>
> You received this message because you are subscribed to the Google Groups "mxunit" group.
> To post to this group, send email to mxu...@googlegroups.com.
> To unsubscribe from this group, send email to mxunit+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mxunit?hl=en.
>
>
>

[Dutch Rapley]

I've been using mxUnit with CF Builder? What is the url for your tests in the browser?

--
Dutch Rapley
www.dutchrapley.com

[DCL]

On Nov 25, 6:47 pm, Marc Esher <marc.es...@gmail.com> wrote:
> I'd suggest clicking the green
> question mark button on the plugin view and reading the first few
> pages of the help files. those should explain exactly what you need to
> do, configuration-wise. basically, you either need to correctly
> configure your 'webroot' preference in window -- preferences -- mxunit
> (probably to something like c:\wherever\workspace) or set the cfc
> path property on your project (right click, properties, mxunit... then
> type "webservice" as the cfcpath.

Unfortunately, still no luck. All of my CF sites are CF Builder
project folders within C:\Users\it01\workspace. This particular site
is in a folder called "webservice." I've read the help but I'm
hampered by not really understanding the use of the term "webroot" in
the docs-- my workspace folder is not a webroot in the sense that I
understand that word.

As you suggested, I set the webroot preference to C:\Users
\it01\workspace, and the cfc path on my project to webservice. Now I
am getting a different error message:

Could not find the Coldfusion Component or Interface

webservice.tests.testName.

It seems we have progressed past failing to find mxunit and now are
failing to find the tests themselves?

Within the webservice directory, there is an mxunit directory and a
tests directory; they are at the same level.

Thanks for your help!

David

[Dutch Rapley]

Try setting the CFC path for your project to . (just the period)

--

You received this message because you are subscribed to the Google Groups "mxunit" group.
To post to this group, send email to mxu...@googlegroups.com.
To unsubscribe from this group, send email to mxunit+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mxunit?hl=en.

--
Dutch Rapley
www.dutchrapley.com

[DCL]

On Nov 30, 10:49 am, Dutch Rapley <dutch.rap...@gmail.com> wrote:
> Try setting the CFC path for your project to . (just the period)

Interestingly, the error message does not seem to change no matter
what I set as the cfc path for my project, whether I put in
"webservice", ".", or just total garbage, I still get Could not find

[DCL]

Just noticed the other thread from Nat Papovich. Unfortunately,
restarting Builder didn't solve the problem for me.

It's also worth noting that I have the following in a .cfm file in the
"webservice" directory... and it runs the tests just fine.

<cfinvoke component="mxunit.runner.DirectoryTestSuite"
method="run"
directory="#expandPath('/tests')#"
recurse="true"
returnvariable="results" />
<cfparam name="url.output" default="extjs">
<cfoutput> #results.getResultsOutput(url.output)# </cfoutput>

[Randy]

You may want to right click on the project and try setting the
component path to . (period) on the project itself. If the webservice
directory isn't the root of the project you will need to do it to the
directory.

If you change the cfc path and the error message doesn't change then
it sounds like there is something closer than the global settings that
is overriding it. If you change the component path to a period it
should change the error message to "Coldfusion Component or Interface
tests.testName." if it took but still gives an error.

Randy

[DCL]

On Nov 30, 11:39 am, Randy <zoram...@gmail.com> wrote:
> You may want to right click on the project and try setting the
> component path to . (period) on the project itself. If the webservice
> directory isn't the root of the project you will need to do it to the
> directory.

Okay. Setting the cfc path to . did work after a second restart of CF
Builder.

So the settings that worked were to use the workspace directory as my
"webroot" in preferences and "." as my cfc path in the project
itself. I have to admit that I don't understand how this is working
and (in particular) whether it will work for other projects but I
guess I'll cross that bridge when I come to it.

David

[Marc Esher]

Sorry I didn't chime in sooner. Let me see if I can clear this up.

Basically, the plugin sees only files: c:\path\to\App1\FileTest.cfc

And it needs to translate that path into a coldfusion dot-notation
path. So, if on your coldfusion server that file is known as
"App1.FileTest", then that's what we need the plugin to tell
ColdFusion. We need it to say "Run App1.FileTest"

Therefore, the plugin's job is to turn c:\path\to\App1\FileTest.cfc
into "App1.FileTest".

How's it do that? Well... that depends on a number of things.

The easiest setup is to use the "webroot". Forget workspace. The
eclipse workspace has nothing to do with files. windows users are
probably familiar with "webroot" because almost always it's
c:\inetpub\wwwroot (at least under IIS), and so for a lot of CF
developers they'll keep all their projects in that directory:

c:\inetpub\wwwroot\App1\
c:\inetpub\wwwroot\App2\

you get the picture.

And then in Eclipse, they'll just set up each project independently:

App1 Project
App2 Project

etc.

So let's say you have a project named "My App1" in Eclipse, and it
points to c:\inetpub\wwwroot\App1

And in there you have a file named FileTest.cfc

And CF knows about that file as App1.FileTest

Well, you have two ways of telling the plugin "hey, turn
c:\inetpub\wwwroot\App1\FileTest.cfc" into "App1.FileTest"

Method 1: set up the "webroot" global preference. When you do that,
you tell the plugin "if you find a file with this webroot in the path,
then chop that entire webroot off of the file path, and turn the rest
of it into CFC notation." For example, if the plugin finds a file
named "c:\inetpub\wwwroot\App1\FileTest.cfc", it says "Oh, I see this
file is underneath the webroot set in the global preferences.
Consequently, chop that part of the path off -- turning the resultant
path into App1\FileTest.cfc From there, just knock off the .cfc
extension and convert \ into ".", and voila, we have App1.FileTest

In this manner, if you keep all your applications under a common root,
then you only ever need to set up that one global preference.

If this doesn't work for people, i.e. they have projects all over the
place or in a place that doesn't have a common root, then you'd need
to set the path at the project level. When you do this, you kind of
kick the plugin into a different kind of mode. It's no longer looking
to find a common prefix to knock off of the file path. Instead, you're
essentially telling the plugin: "For the purposes of this project, XXX
is the "root" from which to start deriving a ColdFusion cfc path.

For example, let's say you have an app at c:\projects\App2\, and you
set up an Eclipse project at that same location. And let's you've set
up a mapping in ColdFusion such that location as "App2". So any CFC
files in there would be App2.MyFile

In this scenario, when you set a project cfc root, the plugin will
derive the cfc path by taking whatever you set that property to, and
then just stuff it onto the path of that file, relative to the project
root. For example, if you have c:\projects\App2\subdir\FileTest.cfc,
and yo'uve set the project's cfcroot property as "App2", then the
plugin will see "subdir\FileTest.cfc", prefix it with "App2" (since
that was the project's property for cfcroot), and then turn that into
the pretty cfc name by stripping the extension and converting slashes
to dots.

If you run eclipse with the "-debug" option in your eclipse.ini file,
the plugin will spit out some information into the Error Log view to
give some guidance on how it's deriving cfc names.

HTH.

Marc

[DCL]

So, in my environment, it sounds like each project is its own root,
even though they are all in a common folder. So when I set "." as my
cfc path, I'm just saying "for this project, treat the project folder
as the web root. In this case the root that I set in preferences is
being ignored, correct?

Thanks for your help!

[Marc Esher]

David,

Let me see if I get this correct:

Your applications live here

C:\Users\it01\workspace

For each application, you have a separate project in Eclipse. One of
them is C:\Users\it01\workspace\webservices

Presumably you've got a mapping set up in CF ADministrator that sets
C:\Users\it01\workspace\webservices to "webservices"

Is that correct?

I'm trying to understand what exactly the correct CFC path is for your
components. Perhaps you could send me some of the names of your other
applications, where htey live on the file system, and how you have
them set up as eclipse (i.e. what the project setup is).

Thanks.

Marc

[DCL]

On Nov 30, 2:14 pm, Marc Esher <marc.es...@gmail.com> wrote:
> Your applications live here
>
> C:\Users\it01\workspace

correct.

> For each application, you have a separate project in Eclipse. One of
> them is C:\Users\it01\workspace\webservices

correct (well, webservice actually)

> Presumably you've got a mapping set up in CF ADministrator that sets
> C:\Users\it01\workspace\webservices to "webservices"

No, we do the mapping in IIS and the hosts file-- no mappings in CF
Administrator. I set a site in IIS to use C:\Users\it01\workspace
\webservice as its Physical Path, then assign a hostname
("lwebservice") via the hosts file. Each of my CF projects has a
corresponding site in IIS, and a corresponding entry in the hosts
file.

> I'm trying to understand what exactly the correct CFC path is for your
> components.  Perhaps you could send me some of the names of your other
> applications, where htey live on the file system, and how you have
> them set up as eclipse (i.e. what the project setup is).

Sure. Some of our other applications are "intranet" and "milty" and
"phillycinema." These are located at:
C:\Users\it01\workspace\intranet
C:\Users\it01\workspace\milty
C:\Users\it01\workspace\phillycinema

Each one of these has a hostname configured in C:\Windows
\System32\drivers\etc\hosts. By group convention, the hostnames used
for development on our local boxes start with "l" so these sites are
accessed via "http://lintranet", "http://lmilty", and "http://
lphillycinema."

From CF's point of view, each one of these is a separate root. (CFCs
that are shared by multiple applications get copied into each
application using svn externals).

I gather this is a somewhat unusual way to set things up in the
development environment. We've come to do it this way because it
allows us to run each application in a configuration that is
substantially similar to how it will be deployed in test/qa/
production, with URL rewriting, authentication, and whatever other
configuration is needed. It also makes it easier to work on two
branches of the same app (using different versions of the same CFCs)
at the same time, something that is often necessary in our development
cycles.

Thanks,
David

[Randy]

To tell the truth, I kind of ignore the webroot directory (mine is
pointed at my coldfusion root)... so i'm not sure how it really
affects things.

I have many projects that aren't even in my workspace, all that mxunit
cares about for the eclipse plugin (from what I have seen) is that you
have the cfc path set correctly for the directory so that mxunit can
use that path as a prefix for your unit tests.

For example. If you have the webservice/ project and you edit the
properties for the project have the cfc path of . then MXUnit will
look for 'test.*' when running unit tests for the 'test' directory. If
you have your site in a sub directory, ex: localhost/mySite, then you
would put 'mySite' in the cfc path so that MXUnit will looking for
'mySite.test.*' to run the tests.

At least that has worked well for me in the past.

Randy

[Marc Esher]

Thanks for the explanation, David. I'd say in your case the best
option is just to stick with using "." as the cfcroot per project.
though I'm honestly not quite sure why setting the webroot as
c:\users\it01\workspace wouldn't work since that should result in
that common prefix being cut off of the path and thus resulting in
"webservice.blah.blah".

Thanks a lot for sticking through this!

Marc

[Randy]

Marc, I think you hit it right on the head :)

I'm guessing he has each of his projects mapped to their own domains:

http://intranet/ => C:\Users\it01\workspace\intranet

So when mxunit cuts off the webroot (c:\users\it01\workspace) it is
left with 'intranet'

But, when MXUnit tries to find 'intranet.test.*' it fails because the
tests are at http://intranet/test/* not http://intranet/intranet/test/*.
When he changes the cfc path on the project to '.' it does the correct
lookup of 'test.*'.

I'm just making this all up, but it makes sense to my limited
understanding... :)

Randy

[DCL]

Yep, Randy has it right. Thanks for all the help, I think I
understand this now.

David

[Marc Esher]

Gotcha. Very clear explanation. Thanks guys!

I guess the question now is: how do we take this and make it so that
the next time this comes along, it's not so damn hard to figure out?
I hate that a guy like David has to spend all this energy just to get
the plugin to figure out it's "test.XXXX" vs. "blahblah.test.XXX"

Any suggestions?

Marc

[DCL]

The biggest issue for me was that changes to the project properties
weren't taking effect without a restart; if that were fixed I might
well have figured this out more quickly. It definitely obfuscates
things when making a change seems to have no effect!

It looks like you've already taken down the text on the web that I
came across last week that made me think the mxunit plugin might not
work in CF Builder... or at least I can't find it any more! So if
that's gone that's a good thing.

There are a few things that could be made clearer in the docs. I
don't think the option of using "." as a cfc path is mentioned at all
in the docs; if I had seen that I certainly would have tried it. I'm
not sure it's totally clear that the project option overrides the
preference option; I was making the mistaken assumption that the two
are used together in some way.

I really don't know how common my configuration is... where each
project is a seperate site. If it's common, it might be worth
mentioning it specifically in the docs; if it's uncommon, it may not
be worth worrying about!

On Nov 30, 6:31 pm, Marc Esher <marc.es...@gmail.com> wrote:
> Gotcha. Very clear explanation. Thanks guys!
>
> I guess the question now is: how do we take this and make it so that
> the next time this comes along, it's not so damn hard to figure out?
> I hate that a guy like David has to spend all this energy just to get
> the plugin to figure out it's "test.XXXX" vs. "blahblah.test.XXX"
>
> Any suggestions?
>

[DCL]

The biggest issue for me was that changes to the project properties
weren't taking effect without a restart; if that were fixed I might
well have figured this out more quickly. It definitely obfuscates
things when making a change seems to have no effect!

It looks like you've already taken down the text on the web that I
came across last week that made me think the mxunit plugin might not
work in CF Builder... or at least I can't find it any more! So if
that's gone that's a good thing.

There are a few things that could be made clearer in the docs. I
don't think the option of using "." as a cfc path is mentioned at all
in the docs; if I had seen that I certainly would have tried it. I'm
not sure it's totally clear that the project option overrides the
preference option; I was making the mistaken assumption that the two
are used together in some way.

I really don't know how common my configuration is... where each
project is a seperate site. If it's common, it might be worth
mentioning it specifically in the docs; if it's uncommon, it may not
be worth worrying about!

On Nov 30, 6:31 pm, Marc Esher <marc.es...@gmail.com> wrote:
> Gotcha. Very clear explanation. Thanks guys!
>
> I guess the question now is: how do we take this and make it so that
> the next time this comes along, it's not so damn hard to figure out?
> I hate that a guy like David has to spend all this energy just to get
> the plugin to figure out it's "test.XXXX" vs. "blahblah.test.XXX"
>
> Any suggestions?
>

[Marc Esher]

Thanks a lot for the feedback, David!

Marc