Updates:
Summary: Alternative extension for test data in plain text files
Status: Accepted
Comment #7 on issue 1018 by pekka.klarck: Alternative extension for test
data in plain text files
http://code.google.com/p/robotframework/issues/detail?id=1018
1) I think this is a good idea. I have actually been thinking about this
myself few times earlier. There are some open questions discussed in points
below that needs to be answered before this can be implemented, though.
2) I don't think support for .txt extension should be removed because:
a) I doubt having multiple extensions for plain text files would cause big
problems in practice. At least there hasn't been too many problems of HTML
files supporting .html, .htm and .xhtml, reST files supporting .rst
and .rest, and in general being able to have
files 'tests.txt', 'tests.html', 'tests.tsv' in same directory.
b) It is often very handy, especially for new users, that you can open .txt
files in Notepad, browsers know how to view them, etc.
c) It would simply be too backwards incompatible change.
3) I can understand that if someone decides to use only certain file type
with test data files, it would be nice if other files would be excluded.
That is a generic and already existing problem not related to this issue,
though. The biggest problem related to this would actually be parsing all
HTML files (including logs and reports) expecting them to contain test
data. A solution I have been thinking for this problem is having an option
like '--excludefiles' that tells Robot to ignore certain files altogether.
You could use that, for example, like `--excludefiles *.txt` or
`--excludefiles *_resource.*`. A separate issue can be submitted about this.
4) If we decide to add a new Robot specific extension, we have a
possibility to add separate extensions for test suites (e.g. .rfs) and
resource files (e.g. .rfr). That would help, for example, RIDE to recognize
file type without parsing the data. I'm not sure is this worth the slightly
added complexity, but this needs to be decided before adding a new
extension. Changing this afterwards would be too much backwards
incompatible.
5) We could potentially also add separate extension for test data in HTML
format. In that case having separate extensions also for suites and
resources would probably be too much.
