Application.cfm and Eclipse plugin
Shannon
Application variables that should be set within the Application.cfm
page.
When I run the same tests from a web based test runner, the tests run
just fine.
I purposely put a syntax error in my application.cfm and tried to run
from both. The web based test runner found the error, but from within
Eclipse it appeared never to hit the application.cfm.
Is this expected behavior? I've worked around it by setting the
variables I need for the tests within the setup() function. But I
didn't know if this was due to user error on my part (I'm still a CF
novice), or to a failure in my Eclipse setup, or to ???
I am testing CFM pages and not CFCs.
Thanks in advance for any help you can give!
Marc Esher
To get your Application.cfm to run when you execute your tests from within Eclipse, you will need to point the plugin to a custom RemoteFacade.cfc.
First, in your application (perhaps just in the root of your app), add a file named RemoteFacade.cfc. So perhaps this will be at c:\inetpub\wwwroot\YourApp\RemoteFacade.cfc
its contents will be:
<cfcomponent extends="mxunit.framework.RemoteFacade"></cfcomponent>
Then, in Eclipse, you'll override the RemoteFacade URL for your project. To do this, go into the project in question in Eclipse, right click, and select "properties"
Select MXUnit Properties in the left pane
Type in the URL to your new RemoteFacade. in this case, it'd be http://localhost/YourApp/RemoteFacade.cfc
and then try running yoru tests
The http requests will now be going to the RemoteFacade.cfc in your application, and your Application.cfm file will be run
Marc
denstar
work like this.
Are you sure it was actually picking up your application.cfm before,
and not the one that was recently deleted?
--heh, never mind, Marc covered it.
I'll go ahead and add the obligatory "you should not rely on scopes,
such as application or session, in your components" type of comment.
This bit me the other day. I cannot recommend other solutions, such
as mock objects, enough. Wish I was smart enough to get more into
them earlier. :)
Huge, *huge* part of "unit" testing right there. Tho I'm happy for
tests of any sort, evil web or no. :)
--
There are two main strategies we can adopt to improve the quality of
life. The first is to try making external conditions match our goals.
The second is to change how we experience external conditions to make
them fit our goals better.
Mihaly Csikszentmihalyi
Marc Esher
you'd look like those people in that movie "The Ring" after they see, well, the Ring, and then their face goes all funky and they go catatonic.
IT is a giant hellball of violating every testing of unit testing you find in "Chapter 1. What not to do, ever" of every unit testing book ever published.
Hopefully when I stand before my maker to have judgement done upon me, he overlooks these transgressions.
denstar
I'm in the midst of untangling over a decade of crappy code writing
(by me, almost solely) at the moment-- so the new devs at least have a
chance of avoiding horrible catatonic states (at least caused by my
old code). I'm sure they'll have plenty of their own to deal with,
given time. :)
Pushing unit tests and what have you pretty hard, trying to pass on
what I've learned*, yadda yadda.
*the hard way
I figure, I'll do what I can, and hopefully it's a kind, loving, and
understanding maker I meet. =)
You cheered me up-- If a master such as yourself isn't perfect, I
don't wanna be either. :)
Gracias, marc!
--
If we cannot live so as to be happy, let us least live so as to deserve it.
Immanuel Hermann Fichte
Marc Esher
It isn't good, but it is what it is. I can definitely tell you that there are certain things about MXUnit -- like the custom remote facades and the actOnTestCase() function inside RemoteFacade -- which were designed precisely for those times where you just gotta work around best practices and do whatever you can to get tests written. I side on "imperfect tests are better than no tests at all".
know what i mean?
Though talk about a cruel teacher... i almost never make these mistakes now that i've fully gotten on board the test train. It's awesome watching how testing can help you get your shit together.
denstar
shit together / Would I get a medal?" for some reason. :)
The rough part is that I'd been tacking on tests, which were really
helpful, but upon major refactoring-- wow. Those were some sucky
tests!
It was like, a test that was mostly for one component, was really
testing 10 others. I knew I was doing that while writing them, to
some extent, but damn. heh.
One of those times where you wish you knew then what you know now, I
guess. But: I'd do it again, so I dunno. See:
I have a contract of sorts, with these tests, and just having to think
about the stuff made it better, and thinking about it again later,
heck, even better.
And shucks, if I'd skipped 'em altogether, that would have *really*
sucked. Yup. Better to do what you can with what you got, and live
to fight another day. Assuming you can always die later, of course.
=)
Practical testing... or pragmatic, perhaps... hrm... I like the sound of that.
Good way of thinking, man. The non-best practice-ish features have
saved me a ton of time, even if sometimes it's cutting corners. I'll
take the bad with the good. Or good with the bad. However that goes.
Heh. I'm rambling. But I feel motivated. This round of tests will be
the best yet!
Yeah! YEAH! <bangs head into monitor a couple times to psyche up>
:den
--
My grandfather once told me that there were two kinds of people: those
who do the work and those who take the credit. He told me to try to be
in the first group; there was much less competition.
Indira Gandhi
Mike Rankin
bother testing existing code, because, well, it's been tested by my
end users. If I have to make changes to existing code (if cfcs even
exist), I always pad my estimate for cleanup. You have to go screwing
with existing, non-component code a lot, but that's pretty much the
nature of re-factoring. I know it totally goes in the face of all the
code coverage concepts, but how often do you get to jam an
architecture on your whole team when your team has no interest in it.
My team still doesn't really grasp the concept of components yet. So
many of them still wind up being UDF bags it's not funny. I'm tempted
to create a com/bewareAllYeWhoEnterHere_tharBeSeaSerpents directory in
many projects.
One of the best tools I use for checking components is the scribblepad
feature in cfeclipse. Invoke a component there and get a result and
you have pretty much eliminated all of the "reaching beyond the walls"
issues.
One of the best developments in a company that I have ever run into is
currently under way where I work. We have a mandate to formally define
our complete software life-cycle process and management understands
that it is something that has to start small and grow over time as the
team matures. Getting the road map in place and letting the whole
team have some input really goes a long way. Just getting basic
concepts defined for everybody works wonders. I've been able to get
ant, hudson, fogbugz, subversion and a solid developer architecture
rolled into the process. I toyed with the idea of code reviews with
jupiter, but figured that would probably tank the process if you put
that in too early. Having a document that explicitly lists all of the
artifacts you are responsible for on a given project is incredibly
useful.
We're still in the definitions phase, but soon we will be looking to
build templates and automation for as many of the artifacts as
possible, The goal being to make their creation and maintenance as
easy as possible. Some of them, like the developer task list, occur
with almost no effort. Once the process is defined from end-to-end,
we'll be able to add in additional refinements and they won't feel so
onerous. I'm toying with the idea of putting in something like
CodeCop to start the code review ball rolling.
Keeping my fingers crossed!
Randy
Did we get your original issue figured out?
Randy
Raffaele Castagno
I'm willing to do the same exact thing, but I fear it will be
difficult to convince them to -invest- in something that does not
generate a direct -income-...
Raffaele
On Sep 18, 4:59 pm, Mike Rankin <anodynep...@gmail.com> wrote:
> I'm a cheater, too, but I do it on the other side. I really don't
> bother testing existing code, because, well, it's been tested by my
> end users. If I have to make changes to existing code (if cfcs even
> exist), I always pad my estimate for cleanup. You have to go screwing
> with existing, non-component code a lot, but that's pretty much the
> nature of re-factoring. I know it totally goes in the face of all the
Shannon
other fun issues.
I think Marc covered it. :)
I will test it out as soon as I can, but Marc has always steered me in
the correct direction! Thanks to you all.... you've been posting some
interesting stuff, I just wish I had time to read all these threads,
but getting my ant build to run mxunit and selenium and find an
intelligent way to load application variables from my build (Kudos to
Sean Corfield, Ben Nadel, and Raymond Camden for giving me the tools
for this last piece) has kept me busy. Some of Marc's blogs on CI with
MxUnit are a ton of help too! Somedays I wish I had a personal blog
to share what you've all led me too... alas, no time! But thanks
all! :)