Dropping support of HTML and TSV formats (Re: open browser keyword not found)

[Pekka Klärck]

2016-05-12 22:12 GMT+03:00 Bryan Oakley <bryan....@gmail.com>:
>> What do people on this list think, should we consider dropping support
>> of TSV and HTML formats?
>
> I'm in favor of removing HTML format. TSV seems dangerous -- doesn't RIDE
> save in TSV? Though, if TSV got dropped it wouldn't affect me at all; the
> last three companies where we used robot all used the plain text format.

RIDE can save using plain text, HTML or TSV. With existing files it
depends on the original format and with new files it depends on
configuration. RIDE should also be able to change the data format.

In general it ought to be pretty safe to remove TSV support because
the plain text parser can parse most TSV files and creating fully
compatible TSV is easy. With HTML we'd lose the possibility to create
test cases that look like normal test documentation with free text,
images, etc. around the test data tables. My assumption is that this
possibility isn't used too much, though, and in that case dropping the
support wouldn't be a big issue. Let us know if I'm wrong with my
assumption!

> I'm in favor of removing HTML because I think it's existence slows down the
> progress of robot. I remember years ago (2012) having a discussion about
> preserving line numbers during parsing, and the response was essentially "we
> won't add it unless we support it in all formats" which was just too big of
> a project for me to tackle. I submitted a PR for the plain text formats, but
> it never got accepted (or even acknowledged). Removing HTML removes one
> hurdle for enhancements such as this.

This is a very good example of something that would be *a lot* easier
if we'd only support the plain text format.

> Are you considering dropping rst as well? I have no opinion on that, other
> than I think it causes the same problems as HTML - it requires more effort
> to support, and potentially slows down progress on the other formats.

We currently support two reST variants: old format that is compiled to
HTML directly and then parsed as normal HTML data, and newer format
that allows embedding plain text test data into reST docs as code
blocks. The former would naturally be lost if we'd drop HTML support,
but I don't see why we could't keep the latter. It's main usage is
supporting free text, images, etc. around test data, so it could be an
alternative for those who use HTML format for the same purpose.

Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

[Taylor, Martin]

My Math testing team would be quite upset if they lost the RF .tsv format for test case files!

Thanks,
Martin

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.
To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at https://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

[Tatu Aalto]

Ugh

We don't use the HTML or TSV format. Also I don't feel strongly on the matter, so from my point of view both can be removed, of course with long depreciation period.

-Tatu

[David]

Just a thought, perhaps file format support could be like some other software applications, and like the RF remote libraries - where Python and Ruby remote servers were originally more part of the project and now split off separately.

The core RF could support one (or maybe more) file format, and we could deprecate/obsolete some current formats. The deprecated/obsolete formats and any new/other formats could be supported via something like a plugin for RIDE, etc. (to read/write non-official formats) and for native RF execution, maybe run the non-official formats through a converter to convert the files first before running via RF or better yet maybe extend pybot, etc.to support file format modules to preparse non-official formats into the official one at runtime (no need to save/store an intermediate converted file).

I understand the hindrances of HTML, but I actually like the format for embedding formatting and metadata with the test data together. I'd think XML, JSON, YAML might make interesting formats as well, although verbose.

This way, RF can work like Selenium community. Focus on the core official stuff (e.g. official Selenium language bindings), and those who prefer the non-official language bindings or rather the deprecated/obsolete file formats in the case of RF, can support it separately outside of the core RF project. Just split off what is there now, and make file format extensible like a protocol/API.

[Pekka Klärck]

2016-05-13 1:21 GMT+03:00 Taylor, Martin <cmta...@ti.com>:
> My Math testing team would be quite upset if they lost the RF .tsv format for test case files!

It would be possible to use the TSV format also in the future even if
we dropped the TSV parser. because the plain text parser can parse TSV
files except for few special cases that are easy to fix in the data.
These parsers also share so much code that keeping them both might be
fine too even if we dropped the HTML format.

[Pekka Klärck]

2016-05-13 8:08 GMT+03:00 David <mang...@gmail.com>:
> Just a thought, perhaps file format support could be like some other
> software applications, and like the RF remote libraries - where Python and
> Ruby remote servers were originally more part of the project and now split
> off separately.
>
> The core RF could support one (or maybe more) file format, and we could
> deprecate/obsolete some current formats.

This is already possible to some extend. You can have test data in any
format and have two ways to execute it:

1. Have a separate tool that converts the data into a format
understood by Robot.

2. Create an executable test suite structure based on the data and run
it. For details see the API docs:
http://robot-framework.readthedocs.io/en/latest/autodoc/robot.running.html

[Sandeep Thapar]

Has something been decided on this aspect ?

Is HTML deprecated by RF ?

Which is the best file format to be used when writing robot test cases ? Our libraries are written in Python.

[Pekka Klärck]

Hello,

No official decision has been made, but the more I think about this
the more I would like to have test data only in plain text files using
the `.robot` extension. reStructeredText files with embedded plain
text data should probably still be supported, but perhaps even they
could require command line option like `--supportReST`. I've been
thinking other formats (HTML, TSV, plain text data with `.txt`
extension) should first be deprecated, but if nobody strongly objects
they could just be dropped in RF 3.1.

Cheers,
.peke

> --
> You received this message because you are subscribed to the Google Groups
> "robotframework-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to robotframework-u...@googlegroups.com.
> To post to this group, send email to robotframe...@googlegroups.com.
> Visit this group at https://groups.google.com/group/robotframework-users.
> For more options, visit https://groups.google.com/d/optout.

[Bryan Oakley]

I think the best solution would be to make the parsers modular and runtime-loadable. The default parser would be the plain text parser, but you could use restructured text with something like `robot --parser=rest`, or html with `robot --parser=html`. Robot could then look for a robot.parsers.rest or robot.parsers.html module, import it, and use it instead of the default. Or for that matter, you wouldn't need to specify anything on the command line. Robot could look at the file extension and then look to see if there's a module matching `robot.parser.<extension>`

That makes it much easier to write new parsers, since they simply need to be coded to a particular API. 

Why would anyone want to write a new parser? For one, I'd like to reimplement the current plain text parser because it throws away line number information, which makes writing tools difficult. I actually have a parser that retains line numbers (and might also be faster that the built-in one), but I've never hooked it up to the robot core because that's just too difficult to do.

I've also seen and heard requests to be able to write and run test cases that are in excel spreadsheets. While you can do that by exporting to tsv (or so I've heard; I've not actually tried it), being able to write a parser that directly reads excel files might be nice. Or, imagine being able to write test cases in a wiki. Or define them in JSON. Or a cucumber parser. There's not a need for any of that in the core of robot, but as someone tasked with supporting different types of teams, having the ability to add custom parsers (even if I'm just subclassing the built-in ones) would really help me do my job.

There's lots of opportunity for people in the community to contribute, but it needs to be easy or nobody will do it. As the parsers are implemented now, replacing them is simply too difficult.  If there were a standard documented interface, writing new parsers would be relatively easy, and it takes the load off of you (Pekka) for having to integrate it with the core. You could port the plain text to this API, and then if someone later needs the HTML format they can (re)create the parser for it without having to learn the internals of robot. 

TL;DR I'm fine with removing all of the formats except for plain text, but maybe this is a good opportunity to make robot more extensible and leave the door open to more easily re-implement them if necessary.

That's my two cents. 

--bryan

> email to robotframework-users+unsub...@googlegroups.com.
> To post to this group, send email to robotframework-users@googlegroups.com.

> Visit this group at https://groups.google.com/group/robotframework-users.
> For more options, visit https://groups.google.com/d/optout.

[Hélio Guilherme]

Hi,

I'm here just to say that I agree 100% on what Bryan wrote:

On Mon, Nov 21, 2016 at 2:10 AM, Bryan Oakley <bryan....@gmail.com> wrote:

I think the best solution would be to make the parsers modular and runtime-loadable. The default parser would be the plain text parser, but you could use restructured text with something like `robot --parser=rest`, or html with `robot --parser=html`. Robot could then look for a robot.parsers.rest or robot.parsers.html module, import it, and use it instead of the default. Or for that matter, you wouldn't need to specify anything on the command line. Robot could look at the file extension and then look to see if there's a module matching `robot.parser.<extension>`

That makes it much easier to write new parsers, since they simply need to be coded to a particular API. 

(...) 

That's my two cents. 

--bryan

Not really 2 cents, but more like $2 or €2 :)

 

[Pekka Klärck]

Hi,

Pluggable parsers would be great. The problem is that I doubt I have
time to design APIs or implement them in the foreseeable future. There
are also already programmatic APIs to create tests that custom parsers
could use. These APIs could probably still be enhanced, but that would
be smaller task than totally re-designing and re-implementing parsing
logic.

I agree retaining line numbers would be really nice. At the moment
that doesn't make much sense with with the HTML format because there
the source code line number isn't too relevant and we should rather
show the logical line number inside a table. This is actually one of
the reasons I'd like to support only the plain text format!

Cheers,
.peke

>> > email to robotframework-u...@googlegroups.com.

>> > To post to this group, send email to

>> > robotframe...@googlegroups.com.

>> > Visit this group at
>> > https://groups.google.com/group/robotframework-users.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Agile Tester/Developer/Consultant :: http://eliga.fi
>> Lead Developer of Robot Framework :: http://robotframework.org
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "robotframework-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to robotframework-u...@googlegroups.com.
> To post to this group, send email to robotframe...@googlegroups.com.

[Frederik Fouvry]

We are using TSV files for our test data (a few thousand, and one test file in HTML), but, as already suggested, I suspect it would be doable to run the data through a converter first. Any support for the conversion would of course be gratefully accepted ;-)

Frederik Fouvry

[adam.wyp...@gmail.com]

Hi,

You can use tidy tool available in RF installation package.

http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#tidy

-Adam.

[Wlad]

Yeah, drop it like it's hot! :-)

No opinion about TSV as I never used it but some words about HTML: I used it in my very beginning with RF. But I used it within a commercial WYSIWYG (what you see is what you get) HTML editor (Dreamweaver by Adobe) which allowed me to edit test case files like normal text document with tables - thus I had not to care about HTML syntax. Editing pure HTML without an editor to create and maintain test cases data is a pain one dont need. But what I liked about HTML was the idea of being able to integrate free text, images and what ever along with executable test case data and to make that available to all stakeholders ... though actually never used this possibility much :-/

Today I use plain text with .robot extension. And if I would need more than plain text one day than reST seem like the better alternatve to HTML.

Cheers

Tset

--

[Pekka Klärck]

2016-11-22 10:16 GMT+02:00 Frederik Fouvry <frederi...@acrolinx.com>:
> We are using TSV files for our test data (a few thousand, and one test file
> in HTML)

Robot's TSV format is actually so close to the plain text format that
the same parser could also parse TSV files. The main difference
between TSV and plain text formats is that the latter requires
escaping empty strings in the test data. It would thus be possible to
support also TSV files even if the dedicated TSV support would be
removed. It would basically just require this:

1. Allow specifying a custom extension to use instead of `robot` for
test data files like `--extension tsv` or `--datapattern '*.tsv'`.
This would also allow using `txt` extension in the future if needed.

2. Document the differences between Robot's current plain text and TSV
parsing so that TSV users could update their data. Updating would be
boring manual work, but luckily that changes are minimal and most data
files ought to work out-of-the-box.

>, but, as already suggested, I suspect it would be doable to run the
> data through a converter first. Any support for the conversion would of
> course be gratefully accepted ;-)

As already mentioned, there's the Tidy tool [1] that you can use for
this purpose:
http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#tidy

[Pekka Klärck]

2016-11-24 15:46 GMT+02:00 Wlad <wagner.w...@gmail.com>:
>
> Today I use plain text with .robot extension. And if I would need more than
> plain text one day than reST seem like the better alternatve to HTML.

Yes, reStructuredText with embedded Robot Framework data have same
benefits as HTML but allow editing using a normal text editor and
generally work better in version control. The Quick Start Guide is a
good example of this approach:
https://github.com/robotframework/QuickStartGuide/blob/master/QuickStart.rst

[pankaj kumar]

We've lots of test cases in HTML format. We follow the concept of 'Living Documentation' and our tests contain images, documentation, complex input/output formats such as Yaml/Pipe Separated text etc. which is only possible in HTML. 

Dropping HTML support would be a big setback for out teams.

[Pekka Klärck]

Hi,

It's very good to know there are teams still using the HTML format.
Benefits of dropping its support from the core framework would be
rather big, so there would need to be more evidence it is actively
used, though.

Have you considered the possibility to use reStructuredText format
instead of HTML? The Quick Start Guide is a good example of how it
looks like:
https://github.com/robotframework/QuickStartGuide/blob/master/QuickStart.rst

Cheers,
.peke

> --
> You received this message because you are subscribed to the Google Groups
> "robotframework-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to robotframework-u...@googlegroups.com.
> To post to this group, send email to robotframe...@googlegroups.com.
> Visit this group at https://groups.google.com/group/robotframework-users.
> For more options, visit https://groups.google.com/d/optout.

[pankaj kumar]

Hi Pekka,

We use Java for running RF test cases (robotframework.jar or maven). As I understand reStructuredText needs to be parsed by Python so it may not be the option for us.

HTML helps us to collaborate effectively with PO/SME during Sprints. HTML allows us to write complex validation in much more readable format and RF allows us to write test cases in plain English which any non technical person can understand.

Was there any decision made on this ? Sorry for coming back after long time as this issue has again cropped up in our internal discussions.

Regards

> email to robotframework-users+unsub...@googlegroups.com.

[Pekka Klärck]

Hello,

reStructuredText is parsed using the docutils module that ought to
support Jython/Java just fine. Could you test how does it work? Should
we consider bundling it into the jar distribution similarly as PyYaml?

The decision to remote the support for the HTML format has pretty much
been done, but no code has yet been removed. Most likely the HTML
format is deprecated in RF 3.1 and then removed in RF 3.2.

Cheers,
.peke

>> > email to robotframework-u...@googlegroups.com.

>> > To post to this group, send email to robotframe...@googlegroups.com.
>> > Visit this group at
>> > https://groups.google.com/group/robotframework-users.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Agile Tester/Developer/Consultant :: http://eliga.fi
>> Lead Developer of Robot Framework :: http://robotframework.org
>

> --
> You received this message because you are subscribed to the Google Groups
> "robotframework-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to robotframework-u...@googlegroups.com.