Skip to main content

More flexible test resources bundling?

2 replies [Last post]
murali_reddy219
Offline
Joined: 2007-10-25
Points: 0

HI Vladimir,

I studied Meframework and TCK developers guide.They had written as follows " we can use the resource files which are in shared subdirectory under classes directory.You must give the path in test description index.html file".

Here i have one doubt.Can we use the same method which we followed for executeArgs case?(i.e can we give the resource path in interview parameters as we did for executeArgs).

Why I am asking is, suppose i had written one test case which needs resource file.I had mentioned the resource file in both test description index.html file and in test case.After that i succesfully completed and Meframework is successfully ruuning.Then i had given my test suite to other user.If he wants to use another resource file to check test case,then he either need to change the resource file name in both test case and in inde.html or he nned to change his resource file name as specified in index.html.

This is my doubt.Cannot we give the resouce file name in interview configuration?
How can we solve thios problem?

I am not an expert.I thought in that way.

Plz tell me what can we do?

Thanks & Regards
Murali

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vsizikov
Offline
Joined: 2004-11-16
Points: 0

Hi Murali,

Interesting questions indeed! :)

> Here i have one doubt.Can we use the same method
> which we followed for executeArgs case?(i.e can we
> give the resource path in interview parameters as we
> did for executeArgs).

Not really. Currently we only support unchangeable paths in "resources" field.
The main reason for that is that we never had a use case to complicate this
approach. And adding dynamic resolution would complicate things for sure.
(For example, some resources might have $ signs in their names, like Class1$InnerClass, and attempt to resolve such name against the test environment
from the interview will lead to a wrong value).

But let's first take a look at your use case and discuss it.
Then we'll see which technical solutions exist.

> Why I am asking is, suppose i had written one test
> case which needs resource file.I had mentioned the
> resource file in both test description index.html
> file and in test case.After that i succesfully
> completed and Meframework is successfully
> ruuning.Then i had given my test suite to other
> user.If he wants to use another resource file to
> check test case,then he either need to change the
> resource file name in both test case and in
> inde.html or he nned to change his resource file
> name as specified in index.html.

I'm not sure that adding question to the interview about the file name would simplify
things significantly. Now, without the question, user would just need to put
his file over the existing one. With interview question (even if it were possible), user would need to know and remember to go to the interview , and to navigate to the file, and you'll need to write the interview question, and the validation for the user input, etc.
All in all, in both cases user performs some manual actions which are better to be avoided, if possible.

OK. If there are few files that you or your users would like to use,
then maybe the best way is just to put them ALL into the
resources directory and ship as part of the test suite,
and create multiple tests, one for each
file. You just need to copy the test description, changing test name and the
resource name (no test sources changes needed).

That way, you'll have multiple tests, each testing different file, and life
is easy: no configuration, no interview complication, no user actions. Users much
more likely will run such test suite (since it's easy).

On the other hand, if you can't predict (or can't obtain) which files users will
try to use, and if the whole point of the test to perform some actions
against any arbitrary content, there are few things to consider.

This will significantly complicate the interview, and the configuration process,
and users will not be happy about complications. One thing is to start the test suite
with no configuration, and another thing is to figure out what should be answered
in interview questions, where to find the files, which files to use, etc.

So, in most cases, we typically try to find good "canonical" content files and ship
them as part of the test suite, and try to avoid too much customization.

In some cases, there is just no way to do that. For example, if we are
testing multimedia functionality of, say, JSR 135 MMAPI, then users
just must provide all the possible media files for all formats they support.

In this case, we ask them to provide a list of URLs in the Interview, and most
URLs are typically HTTP URLs to media files (so that the device could access them).

Then we export the list of the URLs into, say, testMediaURLS variable, and add it into executeArgs for the test.

The test reads the list, and uses the URLs for testing, downloading the content
from the URLs when needed.

This works, and works fine, but it's just a bit more complex. (And it also
indirectly implies that the users need an HTTP server to put files to, but
it is also possible to start small HTTP server when the test suite starts,
for example).

Please also note that in this approach with URL list we don't bundle the
media files with the test bundle, but rather the test itself downloads
the content when needed. This could help with reducing the bundle size.

For example, let's say some user has a huge file for testing.
Most probably, it won't fit into the test bundle, but it still might be possible
to download it via HTTP. Or, some users might have
a hundred files to test. Bundling them all at once might not be possible due to size
constraints, but downloading them one by one is no problem.

> I am not an expert.

Well, you're definitely getting there! :)

Let me know whether you have any additional questions, and it wold be great if you could describe your use case at more detail, this will help up to find the most
appropriate solution for it.

Thanks,
--Vladimir

vsizikov
Offline
Joined: 2004-11-16
Points: 0

Hi Murali,

As you've probably noticed I "branched out" this new question into a separate thread, since it's not relevant to the old thread. And separate threads for separate subjects will help others who might have similar questions.

I'll respond to you question shortly.

Thanks,
--Vladimir