Data Binding broken after setting up a second machine

[corissa]

Hi there all,

I have a fairly specific question about Ranorex that I have been unable to find an answer to. Perhaps you lovely folk can help me out. I have recently been learning the program in the last few weeks so that my workplace is going to permanently implement it as our automated testing tool.

Machine 1: Ranorex v. 6.2.1, running Windows 10
Machine 2: Ranorex v. 6.2.1, running Windows 8

using a Git branch to sync the Ranorex Repository and my test suite between machines

Here's what's happening:

- Machine 1 has Ranorex set up. Set up all my variables, Excel spreadsheets, everything, and my tests are running great on Machine 1. My data binding is killer, I am loving the way I can input variables so far. Key piece here: I saved all my Excel sheets to the project's Repository, so they should not be local to Machine 1.

- THEN I set up Machine 2 to run tests on. The Ranorex Repository and Test Suite look the same as Machine 1. Most of my tests run fine. However, the tests that are accessing the Excel spreadsheets are broken. It keeps saying it cannot access the Data Source.

I don't get why this is happening because I can see them all in the Repository... Seems like they're right there.

So what am I missing? Why can't Machine 2 run the tests exactly the way Machine 1 did? I have the same configuration for Ranorex and Git on Machine 2.

Thanks for any help anyone can provide.

[krstcs]

So, when you say that the Excel sheets are in your repository, what do you mean? Is that a network share? Do you just mean that they are part of your Ranorex solution and in Git?

Ranorex should not be run with any component coming from a network share, all components should be on the local system. This is noted in the User Guide. And, with Ranorex 6.0, since it uses .NET 4.0, security prohibits using data files from somewhere other than the local system.

Are you sure that they path on the second system is correct and that the folder is available? Are you sure that the path is the same on both systems (i.e., that the file is located in the same place)? Are you sure that the data connector's path is correct, and that it is not relative to somewhere that isn't on the second system?


On another note, I would highly recommend using CSV files instead of XLS, as they can be read and edited on any system, while XLS requires that you install the full version of Excel. Excel can still read and save CSV files, so you still get the benefit of the Excel format. The only thing you would lose is worksheets. You would just have to have each worksheet be its own file.

[corissa]

Hi there, I did end up finding a solution. I deleted all my Excel sheets and loaded them in again, making sure that they were in the actual Ranorex Solution rather than stored locally. This has seemed to work repeatedly while syncing with Git.

So, when you say that the Excel sheets are in your repository, what do you mean? Is that a network share? Do you just mean that they are part of your Ranorex solution and in Git?

Yes, they are part of the solution which is also being synced to Git.

On another note, I would highly recommend using CSV files instead of XLS, as they can be read and edited on any system, while XLS requires that you install the full version of Excel. Excel can still read and save CSV files, so you still get the benefit of the Excel format. The only thing you would lose is worksheets. You would just have to have each worksheet be its own file

I did read this, and think about converting to CSV but I am making and will be making hundreds of tests. It seems easier to organize a few Excel worksheets rather than have hundreds of CSVs in the Solution. BUT if you really think that might make it easier, I am all for it. So far the Excel Connector has been the hardest part of Ranorex for me.

So far the second machine is running tests just fine, I just had to make sure the Excel files were stored in the Ranorex Solution and not locally. I know it is recommended to store locally, but we are trying to make Ranorex itself a little more mobile. We may just end up using the Ranorex Agents capability but I am not sure yet. We are still figuring out our setup.

[krstcs]

If Excel is working for you, then by all means, use it. Personally, I wouldn't use Excel (I use SQL Server). I think that Excel is way over-used in test circles. It's an accounting tool, not a testing tool. But, that's just me.

My only real technical issue with Excel is that you have to have it installed on EVERY test system where you will run your tests, while CSV doesn't require any special software. I have 9 VMs that I use regularly for testing, which would mean 9 Office licenses being used, plus needing to manage the installation and updating of Office on top of everything else.

[corissa]

If Excel is working for you, then by all means, use it. Personally, I wouldn't use Excel (I use SQL Server). I think that Excel is way over-used in test circles. It's an accounting tool, not a testing tool. But, that's just me.

My only real technical issue with Excel is that you have to have it installed on EVERY test system where you will run your tests, while CSV doesn't require any special software. I have 9 VMs that I use regularly for testing, which would mean 9 Office licenses being used, plus needing to manage the installation and updating of Office on top of everything else.

Yeah, turns out Excel was causing some other issues because of that exact reason... Installing the FULL version on every test system is super inefficient. Damn, 9 VMs... Haha I will get there some day, but I want to prep for that kind of scale while we are in the early stages of setup.

SQL would be ideal, I may have to look into that. All of our software sits on SQL. Today I switched all my Excel sheets to individual CSVs and things are a lot cleaner and faster when the tests run. I think Excel was bogging it down the whole time.

Thanks again for all your wonderful help!

[krstcs]

You're welcome!

As for the 9 VMs, I'm about to add 8 to 12 more. This is where having a Continuous Integration (CI) solution like Jenkins (recommended, it's free and flexible), Team City, or Bamboo comes in very handy, not just with running tests, but with managing the systems.

As for the SQL Server, I've always been a fan of handling data in a tool designed to handle data, namely a database. I also have a very dynamic test setup so that some test cases are run or not, based on what data is in the parent test case (I alter the SQL queries of the data connectors at runtime). So a DB is really the only way to handle this type of situation. It takes a bit to get set up, but once it is, it's very much worth it. And since Ranorex reports each piece of data in the test report, you have a historical record of what data was used for each test, even if you change the test data later on in the DB.