Documentation of setUp

[Raymond Camden]

I noticed in one of the articles under the Detail page, setup() was
used in a test case. Where is this documented? It is pretty easy to
guess what it does - but I wasn't able to find a formal explanation of
it, it's use, and other methods that are run (presumably)
automatically.

[bill shelton]

Ray,

Thanks for pointing that out. We're revamping the docs, albeit slowly,
and I'll make note. In the interim, the quick answer is that setUp()
is called before each test method in your test case, and tearDown() is
called immediately after, even on a failure or error:

setUp()
yourTest()
tearDown()
...
setUp()
yourOtherTest()
tearDown()
...
etc.

bill

[Sean Corfield]

This is one of those cases where I would encourage folks to read the
documentation on other xUnit frameworks - which all follow the same
pattern. There's a lot of documentation out there about testing that
can be applied to MXUnit...

(sorry, bit of a drive-by comment but I'm catching up on a backlog of
mailing lists)
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Raymond Camden]

Is there any concept of

"before all tests in this component"
"after all tests in this component"

[Martijn van der Woud]

As best practice, your tests should not depend on each other in any
way. You should be able to run any number of them, in any order. I
don't think "before all tests in this component" or "after all tests
in this component" would be of much use if you stick to that practice.
Then again, I would be interested in a good use case to prove me
wrong!

[MikeF]

Hey Ray,

Forgive me if I am mis-reading your question, but I believe the built-
in
setup() & teardown() functions do exactly what you are looking for -
they are inherited from mxunit.framework.TestCase. Not well
documented
imho (sry mxunit guys ;) but really important features of the
framework.

See this thread for more info:
http://groups.google.com/group/mxunit/browse_thread/thread/d295e6b0e04a8757/3d4dfcf1b36897e4?lnk=gst&q=setup#3d4dfcf1b36897e4

hth,

Mike F

On Feb 9, 11:13 am, Martijn van der Woud <martijnvanderw...@gmail.com>
wrote:

[Raymond Camden]

MikeF - the functions setup/teardown run before and after every test
method in my CFC. I expected them to run once. But I know now that
isn't the way it works, nor is it best practice anyway.

On Feb 9, 2:52 pm, MikeF <m...@alluradirect.com> wrote:
> Hey Ray,
>
> Forgive me if I am mis-reading your question, but I believe the built-
> in
> setup() & teardown() functions do exactly what you are looking for -
> they are inherited from mxunit.framework.TestCase. Not well
> documented
> imho (sry mxunit guys ;) but really important features of the
> framework.
>

> See this thread for more info:http://groups.google.com/group/mxunit/browse_thread/thread/d295e6b0e0...
>

[Raymond Camden]

In my use case, I wanted a test user to use through all the methods of
my test component. It doesn't need to be the same user, but I figured
with 5-10 tests, I'd rather just make one test user than 5-10.

On Feb 9, 1:13 pm, Martijn van der Woud <martijnvanderw...@gmail.com>
wrote:

[Marc Esher]

I believe this is slated for addition to MXUnit. I normally get
around the absence of a "BeforeClass" (which is what they call it in
other xUnit frameworks) by just putting stuff in the constructor.
However, there's no "AfterClass" workaround, so to speak, and that's a
place where you'd want to do one-time-only teardown type stuff.

Bill, any idea when this might make it in?

Thanks for bringing this up again Ray. It's one of those features we
probably should have had in there from day 1, but I lump it in with
the other "non-squeaky-wheel" problems... it hardly ever comes up, so
we ignore it and work on other stuff instead. I do know that the last
time we were going to add it, we had started mapping out a completely
new architecture for MXUnit, and this would've been done then, and
then we got distracted with some other features. You know how it goes.

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.
>
>

[Randy Merrill]

Do you know where it would need to be incorporated? Is it just in the test runners and added to the base test?
--
Randy Merrill

[bill shelton]

I've been MIA in the DC blizzard ... but I'm dug out now and should be
able to wire this in the upcoming 2.0 release. i would propose a few
questions (thinking out loud here ...):

1. should this be a naming convention or annotation? E.g.,
- naming would look like <cffuntion name="beforeComponent" ...>
- annotation would look like <cffunction name="whateverIWant"
mxunit:beforeComponent="1" ...> <!--- where '1' is a possible sort
order --->

There are a couple of additional questions that arise out of the
annotation-based implementation. The first one that comes to mind is
what if there are more than one beforeComponent annotations? Should
they all be run, in which order, or should the first or last one be
run, or should it fail? (I'm no sure how TestNG or JUnit handles this
but will check).

With a simple naming convention, it will be guaranteed to be called
only once per TestCase.

2. What should the behavior be if the beforeComponent fails? I would
assume that the entire TestCase fails and no tests in the failed
TestCase are run _or counted_. However, the TestSuite (if present)
would continue to run.

3. I assume that afterComponent would be guaranteed to be _always_
called no matter what, just like tearDown. So, if beforeComponent
fails or errs, the exception stack would be recorded, and the
afterComponent would be called.

4. I would stick with the beforeComponent and afterComponent language
as "component" is a common term in the CF community. The term "class",
though more accurate, IMO, is somewhat of a departure. Thoughts?

Any input is welcome!

best,
bill

[Nick Kaijaks]

Hi Bill,

I'm happy with methods named by convention myself. Annotation sounds like overengineering for a set of run-once methods.

My 2p would be to use something like beforeTests and afterTests, or beforeThis and afterThis, as ...Component might read like it's referring to the class/component *under* test rather than the test class itself.

I'd agree that an after... method should always run; if encapsulation is done properly there shouldn't be much difference between what needs doing after a failed test and after a success (you'd hope :)

Much less sure about failure of before... method. Surely too easy to miss a whole section of potentially faulty code dropping out of a test suite because of something unexpected affecting initialization? I think it'd need to fail/error the suite. Then you can either re-code the initialization to be more robust for whatever's changed, or choose to take the testCase out of the suite.

Best,
Nick

--
Scanned for Warwick Business School by iCritical.