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. 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. Jeff.
________________________________ 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 -~----------~----~----~----~------~----~------~--~---
