Data Driven Testing?
I'm splitting this off after accidentally hi-jacking another thread. Basically what it comes down to is I have to generate a lot of data in the course of testing the services presented to me as thoroughly as possible. Some of our services are significantly large and I end up with hundreds of test cases. The problem stems from the fact that these test cases often require unique data for visibility into issues and for constraints within the service itself. (UUID's, etc).
The problem comes in that the Add requests in these services can, in and of themselves, have hundreds of elements. One of my larger projects right now has 150~ requests (positive and NULL tests, where the null tests contain elements that can be empty or omitted completely). Couple that many requests with the fact that there are ~300 elements per request, you are talking about roughly 45,000 pieces of data that I need access to.
The problem comes in that, to properly test is that I do have to get nitty-gritty and verify data is different because I may have to turn around and update this, which can easily drive my number of test cases and property requests to nearly double.
In the other thread, it was recommended that I look at Data Driven testing and this would be done with Data Sources and Data sinks, etc. I've looked at this and have read up on it and it sounds like something I need to explore. Of course, nothing is ever that simple because I have to keep in mind my own constraints. Namely, however I set this up to test and work has to be easily reproduced by other people. The problem here is that I cannot just set up a database for this, as the other people running my test projects may not have the capability to do the same.
That leaves me with, as far as I can see, using DataSource and files. Is this really the best way to handle this? I could write all of the properties to files and then pull them back in.
Am I missing something here? Am I doing something wrong? I'm relatively new to all of this, as I've been working with SoapUI for only a little over a year.
The problem at hand is I am currently storing all of my data in a Properties step. The more and more properties I have to store, the longer and longer it takes to save/open/close my SoapUI project. Currently, the example project I mentioned with 45,000 properties can take at least 4-5 minutes to open. If I open some of my other projects that are just as large, eventually SoapUI pegs at 100% CPU and 6+GB of memory. My current system has 32gb of memory and a good CPU, but gets bogged down under the strain of the sheer amount of properties.
Any and all advice/help is much appreciated.
