[Meego-community] MeeGo Core Test Suite Development Guideline

[Wang, Jing J]

There is no conflict between xml format and python test script. You can create your favorite test script using python or any language outside xml, then just add a line in xml
<step> python_test_script </step>. 
That's Ok!

-----Original Message-----
From: meego-community-bounces at meego.com [mailto:meego-community-bounces at meego.com] On Behalf Of Sivan Greenberg
Sent: Thursday, June 10, 2010 6:24 AM
To: viroteck at viroteck.net
Cc: meego-community at meego.com
Subject: Re: [Meego-community] MeeGo Core Test Suite Development Guideline

On Thu, Jun 10, 2010 at 12:51 AM, Robin Burchell <viroteck at viroteck.net> wrote:
> On Wed, Jun 9, 2010 at 10:33 PM, Sivan Greenberg <sivan at omniqueue.com> wrote:
> <snip>
>>
>> On Wed, Jun 9, 2010 at 11:52 PM, Robin Burchell <viroteck at viroteck.net> wrote:
>>> On Wed, Jun 9, 2010 at 9:33 PM, Sivan Greenberg <sivan at omniqueue.com> wrote:
>>>> XML is a nice thing, but there's recently too much fuss about pushing
>>>> it into everywhere. I'm curious if that design decision and
>>>> requirements really mandates it ?
>>>
>>> You're asking the wrong question, I think.
>>
>> What's wrong with realizing the rationale behind a technology choice?
>
> Absolutely nothing. So do exactly that. As I said: do you have
> concrete reasoning to not use the technology choice? Rationalise why
> your suggestion is better than what exists now.

Please see the previous threads, I was asking if *another* tool could
be used to write tests then the XML tool. I was not just suggesting a
replacement, although the original verb I used was "instead".

>
> Give concrete reasoning instead of a totally subjective choice like
> your previous example: a language comparison.

I actually prefer Python as a test writing tool. It is proven in the
field of automated QA, and we can do both command line, dbus or
virtually any service with python bindings testing as well as GUI
tests using the same code and syntax (which I'm not sure is possible
with the XML tool, although I'd be happy to stand corrected).

I actually got quite confused with the XML markup when trying to read
the couple examples in the git. It also felt quite inflexible when I
saw the only way to test for FAIL/SUCCESS was the return value to the
shell. Again, anybody is hereby requested to correct me if things are
different.

Reading Python tests is easier on the eye (less markup clutter) and is
more close to pseudo code and natural language.

>
>>> Do you have concrete reasoning to *not* use it, and invent something
>>> which (at the end of the day) will perform very similar or identical
>>> functionally, with different syntax? And likewise, are these reasons
>>> good enough to replace what is already (presumably) finished and
>>> operational?

We're not inventing anything. Python has been around for a while, and
so it seems the natural language way to describe test plans and test
suites, as Valerio noted.

>>
> Actually, no.
>
> Using a *user* interface as a comparison for a tool which will will
> probably *primarily* concern skilled people is a fundamentally flawed
> comparison, to raise my own (similarly subjective) example, it's much
> the same as the mailing lists vs forums eternal debate.
>
> I didn't want to directly involve myself in this particular bikeshed,
> but I think using a different syntax would actually be a *bad*
> decision, given that it involves learning yet another tool, raising
> the barrier to entry (as you so helpfully pointed out that DocBook
> did) instead of reusing something that exists and is quite widely
> known already (XML/SGML/HTML type formats, let's face it, are pretty
> well known).

If the community is of skilled people, then it would not raise the
barrier to entry.
We had this problem when we started the Ubuntu documentation team
because we had end users interested getting involved in documentation!
non technically skilled end users. Would you believe that? ;)
We didn't just tell them "go learn docbook" or "learn ResT" but we
found solutions that enabled them to take their part and feel proud of
it, consequently improving the quality of end product due to broader
crow sourcing.


>
> And the community of contributors are, in general, fairly skilled or
> willing to learn. I honestly don't think that people who haven't at
> least tinkered with a HTML page at some point in the past are going to
> be the number one priority here. Even if you *are* targetting very
> novice users, do you really think that offering a homegrown format
> over a well established markup language is going to help?

Still nothing of the suggested side-by-side solutions are "homegrown".

I appreciate your note of non negativity, but I fail to understand why
my correspondence is negative for that matter.. I am a very positive
person and nobody ever felt I am negative and nonconstructive when
discussing approaches and technologies , or have I ? :)

So my concrete suggestion would be to allow all three:
1) XML is the main and vendor used approach
2) Python for those who like better readability for the testing code
and don't like to fiddle with markup so much. (I'm in this group)
3) Some sort of more natural language way, to allow non techies at
least in the start to contribute or to better describe the issues they
encounter. (they should turn into test plans eventually) This actually
aligns with the user story tracker I once suggested to have.

Sivan
_______________________________________________
Meego-community mailing list
Meego-community at meego.com
http://lists.meego.com/listinfo/meego-community