Sean, et al, An updated version of mxunit (0.9.86-rc1 - http://mxunit.org/download.cfm ) that contains an updated ant task (/mxunit/ant/lib/mxunit-ant.jar) is available for public download. The primary change was to make the outputdir attribute optional, which, if omitted, now has the effect of simply running all the specified tests and printing the summaries to stdout. Remember, you can specify haltonerror/haltonfailure for automated deployments.
If you specify a path for outputdir, the mxunit ant task will write JUnit formatted XML and a results summary properties files to that directory. See the recent tutorial on how to generate JUnit reports, if interested (http://mxunit.org/doc/index.cfm?doc=antjunit) In addition, the error.ratio, failure.ratio, and success.ratio properties in the results have been fixed. For a programmer, my math can be truly horrendous ;-D. The ant task documentation has also been updated (http://mxunit.org/doc/mxunit-ant-doc.html) and has a new example (#1) that shows a minimal build file that runs a directory of tests. thanks! bill On Feb 29, 2:09 pm, "bill[y]" <[EMAIL PROTECTED]> wrote: > Sean, > > > I'm going to download this and try it out this weekend. I see you have > > XML output and an ant task but it wasn't clear whether you could just > > run this as part of a build in Eclipse and have it display pass/fail > > output directly in the console window? (i.e., and not write out XML > > files) > > You know, I was thinking about this last weekend and it does seem a > bit presumptuous to expect that everyone would want to have a detailed > output of all the tests run via the ant task. Some developers would > just rather know how many tests passed or failed, or if any failed or > erred, just halt processing. For me personally, if something broke, I > want to see some details. Likewise, if everything looks good, I want a > record of that. With that said, it would be a simple thing in the ant > task to just set a flag whether or not to write the details. I'll make > that a feature request and try to bang it out this weekend. > > In the interim, you can run a build, but it will still generate the > files which could be removed with a clean task. > > best, > bill > > On Feb 29, 11:44 am, "Sean Corfield" <[EMAIL PROTECTED]> wrote: > > > On Wed, Feb 27, 2008 at 11:14 AM, bill[y] <[EMAIL PROTECTED]> wrote: > > > Key Features: > > > *Easy to see your data with cfoutput, cfdump, and debug() > > > *Easy to run single test functions > > > *Easy "directory runner" for running entire directories of tests > > > *Easy to test private functions in your components > > > *Ability to switch to message-first style assertions to help ease > > > transition > > > from other frameworks > > > *A plethora of output formats from which to choose > > > *Ant Integration > > > *A team actively improving the framework, making testing easier, and > > > providing > > > abundant documentation > > > I'm going to download this and try it out this weekend. I see you have > > XML output and an ant task but it wasn't clear whether you could just > > run this as part of a build in Eclipse and have it display pass/fail > > output directly in the console window? (i.e., and not write out XML > > files) > > > > Q: Why write tests first? > > > A: Because it helps you think about the design and implementation of > > your executable code! > > > (because you have to think about edge cases and limits and error handling) > > -- > > Sean A Corfield -- (904) 302-SEAN > > An Architect's View --http://corfield.org/ > > > "If you're not annoying somebody, you're not really alive." > > -- Margaret Atwood --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
