1

I have a watir test that downloads some information from a web app to an Excel file, and I then open the file to confirm the contents. On my dev box everything works fine, but the scheduled automation runs (via Hudson) always fail attempting to open the Excel file. I have checked that the correct version of AutoITX3.dll is registered on both machines (Ruby 1.8, Watir 1.6.5). No other versions of AutoITx3 are registered on either machine. The error on the Hudson box is the one expected if the dll is NOT registered, but it is present in regedit in the same location as on my dev box. Both machines are WinXP. Running the test manually on the Hudson box results in the same error -- unknown OLE server: 'Excel.Application' HRESULT error code:0x800401f3 Invalid class string.

I searched for similar errors and saw one instance where running on a virtual machine had caused similar problems, but only if the VM window was closed. I don't think this is a code error since it runs on the dev box. Any suggestions for debugging this?

TIA, Sabrina

Željko Filipin
  • 56,372
  • 28
  • 94
  • 125
Sabrina
  • 485
  • 1
  • 5
  • 11

5 Answers5

1

I find the use of Excel to be an antipattern in test automation. I know a lot of people like it, but if you're using that for automation then there are simpler ways to go about it. Consider using CSV with FasterCSV for the automation tests and checking anything into version control which I'm assuming you're using.

IMHO, you should only use Excel when a human is involved - i.e. you may a series of tests defined in CSV, but you edit them in Excel, save back and then diff against what's in a source control system, storing it as CSV.

Excel is useless to diff, so it doesn't store well in a source repo, there's no reason to install it on a CI box when CSV will do and do better.

That's my 2 cents anyhow. :)

Cheers,

Charley

charley
  • 66
  • 1
  • I wasn't clear about the test case ;-) It is a part of the web app functionality that a user can save information to an Excel file. I *have* to use Excel. Not being used to data-drive automation, it is a part of the test itself. – Sabrina Oct 14 '10 at 22:15
1

I would do another search for the issue and leave Watir out of it. I can find several issues for 0x800401f3 associated with FoxPro, Perl, and Oracle.

Dave McNulla
  • 2,006
  • 16
  • 23
1

Have a look at this article http://support.persits.com/show.asp?code=PS01032622

It names the possible causes for your error code.

bq. This error means that either the component has not been registered on the server or the ProgID passed to the Server.CreateObject method is misspelled. On Windows 2003 and XP, it may also mean a permission problem on a system registry key.

I think for you the last one is relevant:

bq. On Windows 2003 and XP, it may also mean a permission problem on a system registry key.

BTW, I googled for ":0x800401f3 Invalid class string." and this was the first result.

Peter Schuetze
  • 16,185
  • 4
  • 44
  • 58
  • 1
    I agree. The problem is that Excel is not installed/registered correctly on the build machine. Perhaps it is not available to all accounts or perhaps the build server is running as a service. The OP's comments about AutoIT are a red herring. – Bret Pettichord Oct 22 '10 at 21:36
  • I can open the exact file, on the test machine, that the test should open and Excel starts up without issue, showing the correct data. Unless there is some other way to test the registry, it appears to be correctly installed. I logged in as the same user that runs the test process, so it isn't a permissions issue either. I wish I could mark this question as answered, but the problem persists. – Sabrina Dec 21 '10 at 20:25
  • Did you try to run the same test manually that Hudson runs? This will be the actual test. The user that runs the test process is the user that Hudson runs under, correct? Or do you switch the user context explicitly within the job? The service comment from Bret P. is only important if the service runs under the local_system account. In this case you need to enable "allow interaction with desktop" (or something similar). But in this case your test will run as local_system. – Peter Schuetze Dec 21 '10 at 21:28
0

What are you trying to test?

  1. That user can open downloaded file with Excel? How do you verify that automatically? With screen shot?
  2. Or that some data is in the file? In that case I would verify contents of the file with something like roo.
Željko Filipin
  • 56,372
  • 28
  • 94
  • 125
  • I am both verifying that the content is correct and that the file is in .xls format that can be opened by Excel. Mostly I'm puzzled by why the test behaves so differently in two ostensibly similar environments (OS, Ruby/Watir versions, etc.). The Universe should be consistent! – Sabrina Oct 21 '10 at 15:34
0

I finally figured it out. What I thought was a working Excel install on the remote machine was instead the free Excel reader, which does not have the API hooks WIN32OLE looks for in the registry. Installed the full Excel program and now everything works. I knew the Universe would be consistent!

Sabrina
  • 485
  • 1
  • 5
  • 11