What's important to your testing needs?
billy
I have framed up our cfunited presentation on "Patterns for
ColdFusion Test Automation" (http://cfunited.com/go/topics/
2008#topic-1743) and would _really_ like to hear for you all about
what you feel is important in this space. What would you like to see
or hear about? I have plenty of ideas about what _I_ want to spew
about, but I think this presentation would be of much better benefit
if it addressed those things that were important to this core group of
Test Driven Dudes/Dudets ... (TDD)
So, if you have a minute or two, please let us know what you would
like to see in your ideal talk on unit testing, test patterns, test
driven development, etc..
thanks,
bill[y]
Peter Bell
Some of the things I'd love to hear about:
Structuring/naming of tests
Mocking - how it works, options in CF, practical examples
Where to put your tests
Test runners and Eclipse integration
Cruise Control
DB solutions - mocking and DBUnit style approaches
Then you've got to decide whether to talk about functional and/or
acceptance testing (e.g. Selenium) and possibly load testing or
whether it's unit testing only.
I'd love something on BDD (see below), but don't think it'd fit into
the existing preso. I may pitch something for next year specifically
on BDD
Behavior Driven Development - the importance of language, they're
specs, not tests, "should" - "given, when, then", working from the
outside in.
Best Wishes,
Peter
ken.sykora
are already pretty much well covered around the web, but i haven't ran
into any really good best practices or case studies on using mxunit on
the web yet. (top 3 items in that list) Over where I work, all our
test cfcs are prefixed with test_ and our deployment scripts know to
ignore these files, but I don't know if there's any better way to do
it that we haven't thought of.
Peter Bell
Re: positioning of tests you might want to read "Pragmatic Unit
Testing with JUnit" from the prag progs - you can get PDF, print or
both and it's full of useful little hints and tips. In brief, you're
going to either create a separate directory for tests so you'll have:
prod/com/model/whatever.cfc
test/com/model/testwhatever.cfc
You might create subdirectories for each directory:
com/model/whatever.cfc
com/model/test/testwhatever.cfc
or you might put the tests in the main directories:
prod/com/model/whatever.cfc
prod/com/model/testwhatever.cfc
Logic behind first one is that in Java if you're using protected
method and both prod and test are in class path you can access
protected methods. Equivalent in CF is package methods, but I haven't
tried to see if it would work in cf - may not . . . Alternative for
package methods in other two scenarios is to put a testwhatever.cfc
that just extends whatever.cfc in the test directory. That way you can
access protected (package) methods.
I like the idea of the first approach, but some like the other
approaches as they keep the tests closer to their code.
What's everyone else doing in the cf world, and why?
Best Wishes,
Peter
Marc Esher
the package pathing, ala example 1.
i've been working with this structure and i like it a lot:
tests/Integration
tests/Unit
tests/Spikes
and then underneath each of those directories i follow the pathing
from my "real" components. Yes, this means I might have
"MyObjectTest.cfc in both the Integration and Unit directories! For
me, I find that a) I don't mind it and b) it keeps the stuff in "unit"
really fast. I put dao/db type tests, file system stuff, and other
hogs in the Integration directory. This may or may not be a best
practice, but so far it's working for me. In addition, since mxunit
supports tests extending other tests, you could have your Integration
version of the test extend teh Unit version. One thing I want to add
into mxunit, after we release version 1 and get to attribute-driven
behavior, is the ability to have a function NOT pass down to a
subclass test. so you could have common fixtures in a main class but
not have the Integration test run everything in the Unit test, for
example.
the "spikes" directory is something I learned from the Test Driven
book by koskela, and I like it. You know those little "tst" files, or
your scribble pad stuff, that you whip up real quick when you're
jamming out some code? Maybe you're just testing some stuff out before
you actually put it into a real file? Well, the idea with spikes is
that if you write it down, why not keep it, just in case? they're
informal, don't need to be cfcs... just normal old files. it's kind of
like a persistent scratch pad.
marc
billy
Marc and I, naturally, are on the same page with test organization.
The spikes concept is new to me, but I really like that. As far as
naming, the one thing I'm running into is that my test classes get big
and feel unruly. I'm finding myself naming them with respect to how
they "aggregate" behavior. So instead of MyClassTest it might be
MyClassReportGeneratorTest. This also may be an indicator that
refactoring the class under test needs refactoring to be more
atomic ... or just smaller.
I've been up to me ears writing a custom MS LogParser Ant task wrapper
in Java and am finding great value using three things:
1. Hamcrest style assertions:
assertThat(files.length,is(greaterThanOrEqualTo(1))); or
assertThat(xsl, containsString("org/mxunit/xant/logparser/xsl/cf-
app.xsl"));
assertThat(actual, is(equalTo("xant-temp")));
This is something we plan to put into MXUnit in 1.1
2. Rich naming ... testThatExecuteGeneratesCSV(), instead of just
testExecute(); This documents and explains the intention well.
Combined with Hamcrest style assertions, this is very expressive.
3. Keeping the tests focused on testing one thing. So, as a "guide",
trying to execute just one assertion per test. Of course, I will write
more, but I'm seeing that each assertion is essentially its own
test ...
Taking a TDD approach, this works for me. When adding something,
though there are tons of things in my head, I "try" to test and write
one thing at a time. Not always easy to do ...
thanks,
bill[y]