On 10/22/07, Jeff Brown <[EMAIL PROTECTED]> wrote:
>
>  There are automatic dialog closer tools out there that you can perhaps
> use.  Pretty much you give them the window title or class id of the dialog
> to be closed and they'll sit in the background and watch for them.
>
> You could even build your own dialog watcher that runs in a background
> thread as part of your test.  You start it up on SetUp.  When a dialog
> appears, you close it and rememeber that such and such dialog appeared.
> During TearDown you clean up the background thread and cause the test to
> fail if a dialog appeared during its execution.
>
> There are many variations on this approach.  I think ultimately it will be
> much more robust than trying to force certain tests to run last.
>

Thanks, it is a good idea. Can you (or anyone else) recommend a good dialog
recording/closing tool with C# API?
I am looking for something that can record info about dialog(s) (one may
lead to another, but they are all simple dialogs) and close it/them, and not
much more than that.
Ideally it should take no more than 2 hours to figure out how to use the
tool

2) You could just run all of the assemblies at the same time with the MbUnit
> console application.  It'll emit a consolidated report which should be just
> what you're looking for.
>
> It is also possible to merge MbUnit reports using XSLT but I don't know if
> anyone's done it yet.  When faced with the same problem, I modified the
> CruiseControl.Net XSLT for generating the HTML report so that it would
> consume multiple report XML files that were trivially combined (end-to-end
> with a new root element) and create a consolidated HTML report.  That turned
> out to be much easier and quite effective.
>

Sounds like a good solution. I'll look into it.

Jeff.
>

Thanks,

- Leonid


------------------------------
> *From:* [email protected] [mailto:[EMAIL PROTECTED] *On
> Behalf Of *Leonid Lastovkin
> *Sent:* Monday, October 22, 2007 10:52 AM
> *To:* [email protected]
> *Subject:* MbUnit How to enforce TestFixture order + How to consolidate
> multiple MbUnit tests results into one + how to access an object model.
>
> Hi,
> I started to run nightly tests at work a few months ago. I am very happy
> that I chose MbUnit as a testing platform.
> With the help of windows task scheduler and some additional C# code, I
> have a test harness in place which grabs fresh code each night,
> builds it, runs the tests, submits every new failure as a bug to an issue
> tracking system (Mantis),
> creates an XML and HTML report  (provided by MbUnit - a very nice
> feature!), saves the report  to where a web server can see it,
> prepares and sends an email with summary of new bugs and a URL link to the
> report. The reporting feature  of MbUnit looks great and saved me a lot of
> time.
>
> It's been working great! It would catch bugs while developers sleep.
> However, the complexity of the testing project is growing, and now I have a
> few questions to ask.
>
> 1) I used to have purely C# tests. Now I also need to test Excel templates
> (.xlt and .xltm) which contain a lot of VBA code in them. I am still doing
> that through MbUnit because I could not find a good tool for Excel/Vba
> testing, plus I want to keep things simple as well as leverage the existing
> features of MbUnit. The Excel testing boils down C# code which:
> A) Starts Excel using COM automation
> B) Instructs Excel to load a particular template file
> C1) Runs a publicly available macro1 in VBA
> ...
> CN) Runs a publicly available macroN in VBA
> D) Grabs the result and reports success/failure + explanation.
> E) Closes Excel
>
> The problem that I am having is that Excel tests fail fairly often  (VBA
> does not have exception handling, and just about any run-time error results
> in a GUI dialog).
> When they do, they just display an error message and sit there until the
> fixture times out.  As the results, only half of the tests actually runs.
> I expect VBA hiccups very frequently while in the middle of development
> cycle, and I need a way to maximize the number of tests that run each night.
>
>
> One of the things I thought about was somehow making Excel-related tests
> execute last. I've seen posts of code that I can use to enforce the order of
> tests within the TestFixture, but what I would really need is a way to
> enforce the order of the Test Fixtures themselves. I should be able to do
> that by adding dependencies to at least (n - 1) of n test fixtures. I am not
> the only one adding the tests, so that would soon break. The only reason why
> I am thinking about the dependencies is because I want to force particular
> tests execute last, not because the dependencies between fixtures arise
> naturally.
>
> Is there a better way?
>
> 2)  One other solution that I thought about would be splitting the
> existing testing project into two - so that one would contain excel tests
> and another would contain regular tests. But, this would double the number
> of emails and the number of reports, unless I write more code to consolidate
> the two. The most difficult part would be consolidating the test report. Can
> that be done? Is there a way for me to take two test results objects, merge
> the two into a single object, and then serialize is to xml/html as a single
> report?
>
> P.S. Being able to consolidate would be kind of nice, as I am going to run
> tests under 4 configurations: Windows XP | Windows Vista x Office 2003 |
> Office 2007.
>
> Thanks.
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"MbUnit.User" 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/MbUnitUser?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to