Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Test and Performance Tools Platform (TPTP) » TPTP & Python
TPTP & Python [message #59273] Mon, 20 March 2006 14:21 Go to next message
Bertrand Quenin is currently offline Bertrand Quenin
Messages: 70
Registered: July 2009
Member
Hi all,

I have a small question about TPTP features. As far as i know, TPTP is
an extensible framework that includes basic "test components" such as
JUnit, Web recording, etc. It's really great like this but as i'm working
on the subject, i think it lacks a (platform independant) scripting
language. I think about Python because it's theorically platform
independant and features many things that are really interresting to use
for test purposes. Moreover, Jython is a pure Java python interpreter that
can be deployed on all JVMs => It's really interresting when deplying test
cases over an IT system.
What about including a "Python test component" on the same level as
JUnit or HTTP ? A Python script that could be added to an artefact and
though deployed as a regular test asset on any target platform ?
Moreover, it would be easy to use datapools (reference classses) in
Python scripts via Jython since the Java bridge is natively support by
this tool. I really think it would be a great thing and i want to know
what you think about it.

Perhaps i'm totally out of my shoes, but i wonder what people think
about this.

Regards
BQ.
Re: TPTP & Python [message #60309 is a reply to message #59273] Mon, 27 March 2006 13:06 Go to previous messageGo to next message
Paul Slauenwhite is currently offline Paul Slauenwhite
Messages: 970
Registered: July 2009
Senior Member
Hi Bertrand,
So are you proposing a test type for testing Python scripts or using
Python scripts as a test asset similar to datapools for the existing test
types? If the latter, what would be the realized benefits of using Python
as opposed to executing a snippet of Java code in a JUnit/URL test? The
manual test type is a likely candidate for automated steps in a manual test.
We have created feature https://bugs.eclipse.org/bugs/show_bug.cgi?id=123277
to support mixed test types so test authors can merge JUnit tests with
manual tests to provide some level of automation when testing manually. I
am really curious about the use case for using a scripting language like
Python as opposed to using a snippet of Java code.

Paul
"Bertrand Quenin" <bquenin@axway.com> wrote in message
news:2d76522d27a103f8fe62bdccaa8bd18e$1@www.eclipse.org...
> Hi all,
>
> I have a small question about TPTP features. As far as i know, TPTP is
> an extensible framework that includes basic "test components" such as
> JUnit, Web recording, etc. It's really great like this but as i'm working
> on the subject, i think it lacks a (platform independant) scripting
> language. I think about Python because it's theorically platform
> independant and features many things that are really interresting to use
> for test purposes. Moreover, Jython is a pure Java python interpreter that
> can be deployed on all JVMs => It's really interresting when deplying test
> cases over an IT system.
> What about including a "Python test component" on the same level as
> JUnit or HTTP ? A Python script that could be added to an artefact and
> though deployed as a regular test asset on any target platform ?
> Moreover, it would be easy to use datapools (reference classses) in
> Python scripts via Jython since the Java bridge is natively support by
> this tool. I really think it would be a great thing and i want to know
> what you think about it.
>
> Perhaps i'm totally out of my shoes, but i wonder what people think
> about this.
>
> Regards
> BQ.
>
Re: TPTP & Python [message #60425 is a reply to message #60309] Mon, 27 March 2006 16:26 Go to previous messageGo to next message
Bertrand Quenin is currently offline Bertrand Quenin
Messages: 70
Registered: July 2009
Member
Hi Paul,

Perhaps I didn't explained my idea very well ... As you know, testers
are not systematically programmers. Currently in TPTP, there only a few
testing schemes that are provided: JUnit, URL/testing and manual tests (I
intentionnaly omit other features like recorder).
The first observation is: JUnit tests are easier to understand by Java
programmers than "old school" programmers (At least, it's the case in my
company).

Moreover, testing needs often include the ability to test C, Cobol,
<place your language here> applications. As far as i know, if i want to
test a C, Cobol, etc. application, i will have trouble if i'm using JUnit.
What i wanted to underline is the fact that JUnit based tests are perhaps
a bit too narrow, too technology specific, if one want to test
heterogeneous technology applications.
The second observation is: JUnit tests don't necessarily fit a C,
Cobol, etc. application tester needs.

That's why i thought about Python, since it's not Java related (as
it's a scripting language) and (a priori) platform independant (Jython:
python interpretter written in Java). Why not implementing a Python test
type (as well as JUnit, or manual) ?? It would allow to create technology
independant test and matches the TPTP formality (test methods, behavior,
etc.).

I was just wondering if this was a good idea and what you think about it ?

Regards
BQ.

PS: Hope i'm clearer than my previous post.
Re: TPTP & Python [message #67027 is a reply to message #60425] Tue, 18 April 2006 20:07 Go to previous messageGo to next message
Paul Slauenwhite is currently offline Paul Slauenwhite
Messages: 970
Registered: July 2009
Senior Member
Hi Bertrand,
Firstly, I think you are making a very valuable point. In fact, we are
dealing with the same requirement with unit testing the native Common Base
Event implementation written in C (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=103538). In this case, we
will write a lightweight JUnit wrapper around our existing C unit test.

Following the idea that TPTP is a test (and performance) tools framework
or platform, consumers and users can easily extend the existing test tools
to provide target language or runtime specific support. An example of
building a custom test type using a scripting language (Perl) as an example
is demonstrated in the "Building a Custom Test Execution Environment"
tutorial:

http://www.eclipse.org/tptp/home/documents/conferences/eclip seCon2005/EclipseCon2005_Tutorial6.pdf

I don't think providing a scripting language test type and execution
environment is more advantageous than making a call to Runtime.exe() from a
JUnit test as opposed to driving a unit test on a script. I would suggest
that TPTP should provide a targeted test type (for example, CUnit) for unit
testing a specific target language.

Please feel free to open a TPTP enhancement for a targeted test type.
Also, contributions from the user/consumer community are always welcome.

Paul
"Bertrand Quenin" <bquenin@axway.com> wrote in message
news:a14d5f5b4513e162787fc104d3c75e55$1@www.eclipse.org...
> Hi Paul,
>
> Perhaps I didn't explained my idea very well ... As you know, testers
> are not systematically programmers. Currently in TPTP, there only a few
> testing schemes that are provided: JUnit, URL/testing and manual tests (I
> intentionnaly omit other features like recorder).
> The first observation is: JUnit tests are easier to understand by Java
> programmers than "old school" programmers (At least, it's the case in my
> company).
>
> Moreover, testing needs often include the ability to test C, Cobol,
> <place your language here> applications. As far as i know, if i want to
> test a C, Cobol, etc. application, i will have trouble if i'm using JUnit.
> What i wanted to underline is the fact that JUnit based tests are perhaps
> a bit too narrow, too technology specific, if one want to test
> heterogeneous technology applications.
> The second observation is: JUnit tests don't necessarily fit a C,
> Cobol, etc. application tester needs.
>
> That's why i thought about Python, since it's not Java related (as
> it's a scripting language) and (a priori) platform independant (Jython:
> python interpretter written in Java). Why not implementing a Python test
> type (as well as JUnit, or manual) ?? It would allow to create technology
> independant test and matches the TPTP formality (test methods, behavior,
> etc.).
>
> I was just wondering if this was a good idea and what you think about it ?
>
> Regards
> BQ.
>
> PS: Hope i'm clearer than my previous post.
>
Re: TPTP & Python [message #67952 is a reply to message #67027] Tue, 25 April 2006 10:12 Go to previous messageGo to next message
Bertrand Quenin is currently offline Bertrand Quenin
Messages: 70
Registered: July 2009
Member
Hi Paul,

If i well understand your point of view, the best solution to
integrate existing tools or non-Java technology tools is to use TPTP as a
front end ? I'm really interrested in your opinion about this because i'm
currently working on a company-wide testing tool project based on TPTP and
everything works perfectly for Java products but i have to think about a
way to integrate existing tool (shell scripts, C tools, perl scripts,
etc.) into this global tool.
In order to integrate all these tools i was thinking about python
because Java is perhaps too sophisticated for testers (they don't have
java programming skills).
On one hand, using java as the main testing language allows a really
quick development of the tool. On the other hand, it may be not well
accepted. If Python is used as the main testing language, I think that the
tool will be more easily accepted by testers but will be harder to develop.

That's why i really wonder what's the best solution.

Thanks for your response.

Regards
BQ.
Re: TPTP & Python [message #69167 is a reply to message #67952] Mon, 01 May 2006 16:19 Go to previous message
Paul Slauenwhite is currently offline Paul Slauenwhite
Messages: 970
Registered: July 2009
Senior Member
Hi Bertrand,
In effect, I am proposing two solutions:

1) Use the existing TPTP JUnit framework to launch existing tests in other
languages to quickly benefit from the existing TPTP tools with few (utility
or helper code) or no new test tools. This solution would be quick but
presupposes the test authors are knowledgeable of Java. This is not a
stretch if you use utility or helper code to launch the existing tests in
other languages. Alternatively, if the test authors are non-technical a GUI
test editor would be required (see bullet #2)

2) Write a custom test to launch existing tests in other languages using an
intermediary language (e.g. Python) which may be simpler for some test
authors but requires a fair amount of new test tools. Coincidentally, this
is same solution as bullet #1 but will an arguably simpler language.

I favor #1 but then again, I am a Java programmer:)

Paul
"Bertrand Quenin" <bquenin@axway.com> wrote in message
news:fe1093c5dcb87e5468d388b13ded8a97$1@www.eclipse.org...
> Hi Paul,
>
> If i well understand your point of view, the best solution to
> integrate existing tools or non-Java technology tools is to use TPTP as a
> front end ? I'm really interrested in your opinion about this because i'm
> currently working on a company-wide testing tool project based on TPTP and
> everything works perfectly for Java products but i have to think about a
> way to integrate existing tool (shell scripts, C tools, perl scripts,
> etc.) into this global tool.
> In order to integrate all these tools i was thinking about python
> because Java is perhaps too sophisticated for testers (they don't have
> java programming skills).
> On one hand, using java as the main testing language allows a really
> quick development of the tool. On the other hand, it may be not well
> accepted. If Python is used as the main testing language, I think that the
> tool will be more easily accepted by testers but will be harder to
develop.
>
> That's why i really wonder what's the best solution.
>
> Thanks for your response.
>
> Regards
> BQ.
>
Previous Topic:object interactions view not available
Next Topic:RAServer Runtime exception
Goto Forum:
  


Current Time: Wed Oct 22 08:06:53 GMT 2014

Powered by FUDForum. Page generated in 0.01894 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software